[Mageia-dev] systemd network.service issues

Fri Mar 16 14:38:55 CET 2012

16.03.2012 14:45, Colin Guthrie kirjoitti:
+> 'Twas brillig, and Anssi Hannula at 16/03/12 03:45 did gyre and gimble:
+>> Hi all!
+>>
+>> So, I've just upgraded my home server to mga2/cauldron.
+>>
+>> Something seems fishy in the network.service handling, systemd thinks it
+>> has failed:
+>>
+>> # systemctl status network.service
+>> network.service - LSB: Bring up/down networking
+>>           Loaded: loaded (/etc/rc.d/init.d/network)
+>>           Active: failed (Result: exit-code) since Fri, 16 Mar 2012
+>> 05:25:09 +0200; 11min ago
+>>           CGroup: name=systemd:/system/network.service
+>>                   ├ 4679 /sbin/ifplugd -I -b -i eth0
+>>                   ├ 4723 /sbin/ifplugd -I -b -i eth1
+>>                   └ 5372 /sbin/dhclient -q -lf
+>> /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf
+>> /etc/dhclient-eth0.conf...
+>>
+>> Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Using detection mode:
+>> SIOCETHTOOL
+>> Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Initialization
+>> complete, link beat not detected.
+>> Mar 16 05:25:09 delta.onse.fi network[4397]: [161B blob data]
+>> Mar 16 05:25:09 delta.onse.fi network[4397]: [14B blob data]
+>> Mar 16 05:25:13 delta.onse.fi ifplugd(eth0)[4679]: Link beat detected.
+>> Mar 16 05:25:14 delta.onse.fi ifplugd(eth0)[4679]: Executing
+>> '/etc/ifplugd/ifplugd.action eth0 up'.
+>> Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPREQUEST on eth0 to
+>> 255.255.255.255 port 67
+>> Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPACK from 109.204.128.1
+>> Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: client: Determining
+>> IP information for eth0... done.
+>> Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: Program executed
+>> successfully.
+>>
+>>
+>> Trying to restart it I seem to hit other issues:
+>>
+>> # systemctl restart network.service
+>> Job failed. See system journal and 'systemctl status' for details.
+>> # systemctl status network.service
+>> network.service - LSB: Bring up/down networking
+>>           Loaded: loaded (/etc/rc.d/init.d/network)
+>>           Active: failed (Result: exit-code) since Fri, 16 Mar 2012
+>> 05:36:39 +0200; 3s ago
+>>          Process: 8027 ExecStart=/etc/rc.d/init.d/network start
+>> (code=exited, status=1/FAILURE)
+>>           CGroup: name=systemd:/system/network.service
+>>                   ├ 8195 /sbin/ifplugd -I -b -i eth0
+>>                   └ 8353 /sbin/dhclient -q -lf
+>> /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf
+>> /etc/dhclient-eth0.conf...
+>>
+>> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists
+>> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists
+>> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists
+>> Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists
+>> Mar 16 05:36:39 delta.onse.fi dhclient[8261]: DHCPREQUEST on eth0 to
+>> 255.255.255.255 port 67
+>> Mar 16 05:36:40 delta.onse.fi dhclient[8261]: DHCPACK from 109.204.128.1
+>> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: Determining
+>> IP information for eth0...NETLINK: Error: File exists
+>> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client:  done.
+>> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: NETLINK:
+>> Error: File exists
+>> Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: Program executed
+>> successfully.
+>>
+>> Any ideas? If not, I'll investigate this myself later.
+> 
+> network.service fails here too, but I've not been able to work out
+> exactly why. It doens't bother me too much tho' as all my devices are
+> using network manager!
+> 
+> THat said, it seems that network.service has still started an ifplugd
+> for my wlan, despite the ifcfg file clearly saying that NM should take
+> care of that interface... needs some investigating for sure.
+> 
+> 
+>> On a related note, I also got dropped to emergency console on first
+>> boot, not sure why was that (it didn't tell me the reason... maybe the
+>> reason was in another virtual console, but I didn't remember to check
+>> there at the time). I just exited the console and it continued to boot...
+> 
+> Interesting. Was it a dracut shell or a systemd one? (sometimes hard to
+> tell which is which, but the text usually tells you.
+
+I think it was a systemd one (it seemed to be quite late in the boot,
+when I exited it the next thing it did was build DKMS stuff).
+
+> Knowing which should help identify why. Does it happen on subsequent boots?
+
+No idea yet, but will reboot the system now.
+
+>> I see the following in systemctl --failed:
+>>
+>> # systemctl --failed
+>> UNIT                         LOAD   ACTIVE SUB    JOB DESCRIPTION
+>> bootparamd.service           loaded ESC[1;31mfailed failedESC[0m
+>> SYSV: The bootparamd server allows older Sun workstations to net boot
+>> from Linux boxes. It (along with rarp) is rarely used anymore; bootp and
+>> dhcp have mostly replaced both of them.
+>> fedora-loadmodules.service   loaded ESC[1;31mfailed failedESC[0m
+>> Load legacy module configuration
+> 
+> dmorgan reported this as well, but it's a really simple script and
+> really shouldn't fail.
+> 
+> I think it must be the /etc/rc.modules script that is likely failing
+> here. Perhaps trying to modprobe a module that no longer exists due to
+> old configuration? If possible can you debug the fedora-load-modules
+> service and comment out one half of the script such that only the
+> rc.modules bit is run and confirm that's where it's bust. Then maybe
+> work out what in rc.modules is broken. That woudl be useful as it works
+> fine here.
+
+Actually it is because /etc/modprobe.preload contains some non-existing
+modules (like psmouse), and /etc/modprobe.preload.d/cpufreq
+(cpufreq_performance).
+
+bootparamd failed because I had no /etc/bootparamd. I'm pretty sure I've
+not installed bootparamd myself, but it was a leaf package now so I
+simply removed it.
+
+>> network.service              loaded ESC[1;31mfailed failedESC[0m
+>> LSB: Bring up/down networking
+> 
+> Mentioned above. Needs to be debugged.
+> 
+>> systemd-modules-load.service loaded ESC[1;31mfailed failedESC[0m
+>> Load Kernel Modules
+> 
+> Yeah this one fails for me too. Not sure why, but maybe because I've
+> done something stupid and symlinked stuff into /etc/modules-load.d when
+> I shouldn't. I'll look into it.
+
+I guess this would be for the same reason as fedora-loadmodules.service...
+
+BTW, isn't this duplication? Well, I guess not completely,
+/etc/modules-load.d doesn't contain the stuff from
+/etc/modprobe.preload.d/, only /etc/modprobe.preload and /etc/modules.
+
+> 
+> Incidentally, just answering your private tmp question from IRC...
+> 
+> This is what Lennart had to say about it:
+> <mezcalero> coling: the /tmp dir used by PrivateTmp lies beneath /tmp
+> <mezcalero> coling: hence, if /tmp is cleaned up those private tmps will
+> be cleaned up too
+> <mezcalero> coling: since the clean-up is recursive
+
+Ah, clever. Though I should've recognized it was just a simple
+bind-mount... I'll blame my tiredness for this as well :)
+
+-- 
+Anssi Hannula
+