Bug#754218: boot hangs forever on LSB job raise network interfaces
On 12/16/2014 06:13 PM, Julien Cristau wrote: I'm pretty sure what you ran into is a different issue, see https://bugs.debian.org/771943. Cheers, Julien You're right. It looks more like the bug you mentioned. Best regards, Jochen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Mon, Dec 15, 2014 at 13:34:28 +0100, Jochen Bartl wrote: Hi *, I ran into the same problem. The boot time has increased almost by one minute since an upgrade recently. $ sudo systemd-analyze blame 1min 1.970s networking.service 1.158s systemd-udev-settle.service 1.145s uml-utilities.service 409ms tor.service ... After having a look at the log files I found out that the DHCP client tries to get an address on eth0. But I'm on WLAN (wlan0) and there isn't even a cable plugged in on eth0. As soon as I comment the eth0 lines in /etc/network/interfaces out, the problem is gone. But I guess that's not a proper solution. I'm pretty sure what you ran into is a different issue, see https://bugs.debian.org/771943. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
Hi *, I ran into the same problem. The boot time has increased almost by one minute since an upgrade recently. $ sudo systemd-analyze blame 1min 1.970s networking.service 1.158s systemd-udev-settle.service 1.145s uml-utilities.service 409ms tor.service ... After having a look at the log files I found out that the DHCP client tries to get an address on eth0. But I'm on WLAN (wlan0) and there isn't even a cable plugged in on eth0. As soon as I comment the eth0 lines in /etc/network/interfaces out, the problem is gone. But I guess that's not a proper solution. My /etc/network/interfaces: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp $ systemd sudo systemctl status networking.service networking.service - LSB: Raise network interfaces. Loaded: loaded (/etc/init.d/networking) Drop-In: /run/systemd/generator/networking.service.d └─50-insserv.conf-$network.conf Active: active (running) since Mon 2014-12-15 12:57:02 CET; 20min ago Process: 1951 ExecStart=/etc/init.d/networking start (code=exited, status=0/SUCCESS) CGroup: /system.slice/networking.service └─2176 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 $ sudo journalctl _SYSTEMD_UNIT=networking.service -- Logs begin at Mon 2014-12-15 12:55:59 CET, end at Mon 2014-12-15 13:19:21 CET. -- Dec 15 12:56:01 k0ld dhclient[2156]: Internet Systems Consortium DHCP Client 4.3.1 Dec 15 12:56:01 k0ld dhclient[2156]: Copyright 2004-2014 Internet Systems Consortium. Dec 15 12:56:01 k0ld dhclient[2156]: All rights reserved. Dec 15 12:56:01 k0ld dhclient[2156]: For info, please visit https://www.isc.org/software/dhcp/ Dec 15 12:56:01 k0ld dhclient[2156]: Dec 15 12:56:01 k0ld networking[1951]: Configuring network interfaces...Internet Systems Consortium DHCP Client 4.3.1 Dec 15 12:56:01 k0ld networking[1951]: Copyright 2004-2014 Internet Systems Consortium. Dec 15 12:56:01 k0ld networking[1951]: All rights reserved. Dec 15 12:56:01 k0ld networking[1951]: For info, please visit https://www.isc.org/software/dhcp/ Dec 15 12:56:01 k0ld dhclient[2156]: Listening on LPF/eth0/f0:de:f1:90:28:7f Dec 15 12:56:01 k0ld dhclient[2156]: Sending on LPF/eth0/f0:de:f1:90:28:7f Dec 15 12:56:01 k0ld dhclient[2156]: Sending on Socket/fallback Dec 15 12:56:01 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 Dec 15 12:56:01 k0ld networking[1951]: Listening on LPF/eth0/f0:de:f1:90:28:7f Dec 15 12:56:01 k0ld networking[1951]: Sending on LPF/eth0/f0:de:f1:90:28:7f Dec 15 12:56:01 k0ld networking[1951]: Sending on Socket/fallback Dec 15 12:56:01 k0ld networking[1951]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 Dec 15 12:56:08 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13 Dec 15 12:56:08 k0ld networking[1951]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13 Dec 15 12:56:21 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16 Dec 15 12:56:21 k0ld networking[1951]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16 Dec 15 12:56:37 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16 Dec 15 12:56:37 k0ld networking[1951]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16 Dec 15 12:56:53 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 Dec 15 12:56:53 k0ld networking[1951]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 Dec 15 12:57:02 k0ld dhclient[2156]: No DHCPOFFERS received. Dec 15 12:57:02 k0ld dhclient[2156]: No working leases in persistent database - sleeping. Dec 15 12:57:02 k0ld networking[1951]: No DHCPOFFERS received. Dec 15 12:57:02 k0ld networking[1951]: No working leases in persistent database - sleeping. Dec 15 12:57:02 k0ld networking[1951]: done. Dec 15 13:00:20 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 Dec 15 13:00:28 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13 Dec 15 13:00:41 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18 Dec 15 13:00:59 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20 Dec 15 13:01:19 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2 Dec 15 13:01:21 k0ld dhclient[2176]: No DHCPOFFERS received. Dec 15 13:01:21 k0ld dhclient[2176]: No working leases in persistent database - sleeping. Dec 15 13:04:11 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 Dec 15 13:04:17 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12 Dec 15 13:04:29 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
Bug#754218: boot hangs forever on LSB job raise network interfaces
Control: tag -1 moreinfo On Lu, 01 dec 14, 18:15:22, tv.deb...@googlemail.com wrote: I did so, when switching to VT 9 the screen is spamed with the systemd message about starting LSB. I typed blindly journalctl -alb and noticed that a shell session was indeed active behind the spam wall ! Could you also attach the output to this bug? I can see that the driver e1000 for the network card is loaded early without problem. I have very few errors, I get: failed to find module 'lp' and same for 'ppdev' , which in turn generates several fail warnings later on for systemd load kernel modules. You probably have some modules in /etc/modules or /etc/modprobe.d/ that fail to load. Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh There is no /usr/lib/systemd/scripts directory on my system (system is mdadm raid + LUKS). apt-file search didn't tell me what package is supposed to provide this mdadm_env.sh script, and find didn't show it on my system either. This might be bogus, but a little more details about your setup wouldn't hurt. ERROR : Duplicate address 192.168.1.2 assigned in the network where eth1 is connected to The last one puzzles me as at the time I booted I was the only machine on the network, and address is assigned from the DHCP server (openwrt) through MAC address reservation. grepping through /etc for string 192.168.1.2 show one occurrence in /etc/hosts, one in /etc/samba/lmhosts, and one in backuppc configuration. arp shows no address or MAC conflict on the network, and my router doesn't either. Finally I did pgrep network and killed the corresponding PID to get the boot process to resume. It did successfully and the system is fully functional, including networking, raid and all, which makes me think some of the failure reports may be bogus ? Please attach also your /etc/network/interfaces. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Wed, 10 Dec 2014 12:23:15 +0200 Andrei POPESCU andreimpope...@gmail.com wrote: Control: tag -1 moreinfo On Lu, 01 dec 14, 18:15:22, tv.deb...@googlemail.com wrote: I did so, when switching to VT 9 the screen is spamed with the systemd message about starting LSB. I typed blindly journalctl -alb and noticed that a shell session was indeed active behind the spam wall ! Could you also attach the output to this bug? I can see that the driver e1000 for the network card is loaded early without problem. I have very few errors, I get: failed to find module 'lp' and same for 'ppdev' , which in turn generates several fail warnings later on for systemd load kernel modules. You probably have some modules in /etc/modules or /etc/modprobe.d/ that fail to load. Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh There is no /usr/lib/systemd/scripts directory on my system (system is mdadm raid + LUKS). apt-file search didn't tell me what package is supposed to provide this mdadm_env.sh script, and find didn't show it on my system either. This might be bogus, but a little more details about your setup wouldn't hurt. ERROR : Duplicate address 192.168.1.2 assigned in the network where eth1 is connected to The last one puzzles me as at the time I booted I was the only machine on the network, and address is assigned from the DHCP server (openwrt) through MAC address reservation. grepping through /etc for string 192.168.1.2 show one occurrence in /etc/hosts, one in /etc/samba/lmhosts, and one in backuppc configuration. arp shows no address or MAC conflict on the network, and my router doesn't either. Finally I did pgrep network and killed the corresponding PID to get the boot process to resume. It did successfully and the system is fully functional, including networking, raid and all, which makes me think some of the failure reports may be bogus ? Please attach also your /etc/network/interfaces. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt Hi, thank you for your attention but since I am not the original submitter of this bug and was under the impression that it was solved (a workaround has been found) I didn't want to add more noise. I will open a new bug if I switch back to systemd and still experience the issue. My interfaces file is attached to my first message, together with dhcp conf. I am looking into the modules error, I do have quite a few ones in modules.conf, historical heritage and probably unnecessary now, but not the ones mentioned in the logs. I will generate and attach a new boot log when I get a chance to run this system with systemd again, maybe this week-end. This system is LUKS over RAID1 (mdadm), no lvm. /boot, /root and /home separate, plus other data and backup arrays that get mounted with a combination of pam_mount, key-file and decrypt_derived . /root is encrypted too, I get to install plymouth whenever I want to test systemd to be able to see the various password prompts. This plymouth thing should be a suggest for systemd with a comment about Luks encrypted partitions, that's another story. Regarding /usr/lib/systemd/scripts, I don't find it with apt-file search, I don't know what package is supposed to create it. Do you have this directory on your (Testing/Sid) systems, I don't have it on any ! Thank you again, you can disregard this reply if this is considered irrelevant to the bug, I will open a new one when I can test this again. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
On 2014-12-01 16:32, Michael Biebl wrote: Does the system itself boot correctly? Yes. How does your /etc/network/interfaces look like? Default configuration. Like Stefano Zacchiroli's, without last two IPv6 lines: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=interfaces;att=1;bug=754218 After reading further explanations, I understand this workaround for broken software is unpleasant but necessary for Jessie release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
Dear all, same happening here: Debian Jessie/Unstable amd64 up-to-date. systemd: Version : 215-7 shorewall installed and configured NO nfs mount of any kind NO network mount of any kind NetworkManager NOT installed (/etc/network/interfaces used) NO local custom init script Additionally this machine as two wired network interfaces (configured) and one wireless (not configured), when the hang occurs it sometimes (rarely, twice in a dozen try, some left to hang for 30minutes) proceeds to boot. When this happens the second interface eth1 (Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) ) is not appearing in ifconfig. When this occurs I can not modprobe the driver (e1000) manually, nor bring the interface by any mean ! I suspected a hardware/bios initialization bug but the same interface works flawlessly with sysvinit-core and systemd-shim, as with rescue system System Rescue CD. /etc/network and /etc/dhcp attached. Only workaround was to chroot from rescue system and switch back to sysvinit manually. I can reinstall systemd as init and make the system fail again (outside of office hours ;-) ) if provided with direction as to how collect additional information. Thank you for your work and attention, All the best. dhcp_network.tar.gz Description: application/gzip
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Lu, 01 dec 14, 14:12:01, tv.deb...@googlemail.com wrote: I can reinstall systemd as init and make the system fail again (outside of office hours ;-) ) if provided with direction as to how collect additional information. Please enable the debug console on VT9 (boot with 'systemd.debug-shell' as kernel parameter) and attach the output of journalctl -alb Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Mon, 1 Dec 2014 13:35:04 +0200 Andrei POPESCU andreimpope...@gmail.com wrote: On Lu, 01 dec 14, 14:12:01, tv.deb...@googlemail.com wrote: I can reinstall systemd as init and make the system fail again (outside of office hours ;-) ) if provided with direction as to how collect additional information. Please enable the debug console on VT9 (boot with 'systemd.debug-shell' as kernel parameter) and attach the output of journalctl -alb Kind regards, Andrei I did so, when switching to VT 9 the screen is spamed with the systemd message about starting LSB. I typed blindly journalctl -alb and noticed that a shell session was indeed active behind the spam wall ! I can see that the driver e1000 for the network card is loaded early without problem. I have very few errors, I get: failed to find module 'lp' and same for 'ppdev' , which in turn generates several fail warnings later on for systemd load kernel modules. Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh There is no /usr/lib/systemd/scripts directory on my system (system is mdadm raid + LUKS). apt-file search didn't tell me what package is supposed to provide this mdadm_env.sh script, and find didn't show it on my system either. ERROR : Duplicate address 192.168.1.2 assigned in the network where eth1 is connected to The last one puzzles me as at the time I booted I was the only machine on the network, and address is assigned from the DHCP server (openwrt) through MAC address reservation. grepping through /etc for string 192.168.1.2 show one occurrence in /etc/hosts, one in /etc/samba/lmhosts, and one in backuppc configuration. arp shows no address or MAC conflict on the network, and my router doesn't either. Finally I did pgrep network and killed the corresponding PID to get the boot process to resume. It did successfully and the system is fully functional, including networking, raid and all, which makes me think some of the failure reports may be bogus ? What makes me really skeptic of systemd behavior here is the impossibility to kill a stalled process and resume boot without first rebooting in systemd debug mode, or at least get a sane timeout (and advertise it so that users can wait). Thank you for your assistance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
Package: systemd Version: 215-7 I can't help, don't even know if this is systemd related, but I've noticed about 15 seconds delay while looking at: [ *** ] A start job is running for LSB: Raise network interfaces. since recent ifupdown 0.7.50 upgrade. apt-get --reinstall install ifupdown=0.7.49 and hold, solved this for now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 01.12.2014 um 16:57 schrieb Alex Mayer: Package: systemd Version: 215-7 I can't help, don't even know if this is systemd related, but I've noticed about 15 seconds delay while looking at: [ *** ] A start job is running for LSB: Raise network interfaces. since recent ifupdown 0.7.50 upgrade. Does the system itself boot correctly? How does your /etc/network/interfaces look like? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
I'm having the same issue,... so maybe it comes from #766943? I've only checked the fix for that on the server nodes (where that delay of 1-2 mins doesn't really get noticed) - not on my desktop node. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 01.12.2014 um 17:48 schrieb Christoph Anton Mitterer: I'm having the same issue,... so maybe it comes from #766943? Very likely, yes. If you use DHCP, it can easily take a few seconds for your network to be configured. And now that /etc/init.d/networking both handles allow-hotplug and auto interfaces and blocks for ifup to complete for those interfaces, the delay during boot is kinda expected. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Mon, 2014-12-01 at 18:00 +0100, Michael Biebl wrote: Very likely, yes. If you use DHCP, it can easily take a few seconds for your network to be configured. And now that /etc/init.d/networking both handles allow-hotplug and auto interfaces and blocks for ifup to complete for those interfaces, the delay during boot is kinda expected. So can we keep the other fix as it is? I mean this will just cause another stupid systemd-is-responsible-and-it-sucks hatred storm by people... :( smime.p7s Description: S/MIME cryptographic signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 01.12.2014 um 18:08 schrieb Christoph Anton Mitterer: On Mon, 2014-12-01 at 18:00 +0100, Michael Biebl wrote: Very likely, yes. If you use DHCP, it can easily take a few seconds for your network to be configured. And now that /etc/init.d/networking both handles allow-hotplug and auto interfaces and blocks for ifup to complete for those interfaces, the delay during boot is kinda expected. So can we keep the other fix as it is? I mean this will just cause another stupid systemd-is-responsible-and-it-sucks hatred storm by people... :( Not quite sure what you mean with other fix? Can you elaborate? You can't eat a cake and have it too. Either we wait blockingly (and wait actually means, well, delaying your boot process and making it slower) for ifup to complete during boot as workaround for broken software which doesn't deal with dynamic network changes and requires $network, or we don't blockingly wait and cause that other software to break. For jessie we decided to take that boot delay hit in exchange for supporting $network requiring software. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Mon, 2014-12-01 at 18:55 +0100, Michael Biebl wrote: Not quite sure what you mean with other fix? Can you elaborate? I mean the udevsettle, which apparently causes this delay now... I just see it coming that gazillions of people cause to whine about that delay :( For jessie we decided to take that boot delay hit in exchange for supporting $network requiring software. Okay.. I'm fine with it :) smime.p7s Description: S/MIME cryptographic signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
I stumbled over this bug while investigating the same symptoms on my laptop with testing. After a loss of power I rebooted and it seemingly hung on fsck (last visible line was something with systemd-fsck), but on rebooting in recovery I got the [ *** ] A start job is running for LSB: Raise network interfaces. as well. I fixed it by booting single user mode and removing firestarter, which I suspected, as it was the only result of grep -r restart /etc/network I have systemd 208-8. Greetings, Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
Today, after upgrading kde, sysvinit-core was replaced with systemd-sysv
208-8. Reboot gives the same error.
Boot becomes normal after auto entries were committed out in
/etc/network/interfaces (except lo). Not workable file is attached.
--
sergio.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
auto lo
auto eth0
auto foo
auto foo-vpn
auto bar-vpn
auto wlan-base
iface lo inet loopback
iface eth0 inet static
address IP/24
gateway IP
iface wlan-ap inet static
address IP/24
iface wlan-base inet static
address IP/24
iface foo inet static
address IP/24
pre-upip tuntap add dev ${IFACE} mode tap one_queue
post-down ip link del ${IFACE}
iface foo-vpn inet manual
openvpn foo
iface bar-vpn inet manual
openvpn bar
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 04.09.2014 um 01:43 schrieb sergio: Today, after upgrading kde, sysvinit-core was replaced with systemd-sysv 208-8. Reboot gives the same error. Boot becomes normal after auto entries were committed out in /etc/network/interfaces (except lo). Not workable file is attached. Could you please send me all files from /etc/network/ and /etc/dhcp/ (as tarball). Thanks -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On 09/04/2014 04:29 AM, Michael Biebl wrote:
Could you please send me all files from /etc/network/ and
/etc/dhcp/ (as tarball).
There are no custom files in /etc/network, do you really need them?
% ls -R /etc/network
/etc/network:
if-down.d/ if-post-down.d/ if-pre-up.d/ if-up.d/ interfaces.d/
interfaces run@
/etc/network/if-down.d:
openvpn* upstart* wpasupplicant@
/etc/network/if-post-down.d:
hostapd@ wpasupplicant@
/etc/network/if-pre-up.d:
ethtool* hostapd@ wpasupplicant@
/etc/network/if-up.d:
ethtool* mountnfs* openssh-server* openvpn* upstart* wpasupplicant@
/etc/network/interfaces.d:
%
And only dhcpd.conf is modified in /etc/dhcp :
% ls -R /etc/dhcp
/etc/dhcp:
dhclient-exit-hooks.d/ dhcpd.conf dhcpd.conf.orig
/etc/dhcp/dhclient-exit-hooks.d:
ntp
% cat /etc/dhcp/dhcpd.conf | grep -v '^#' | grep -v '^$'
authoritative;
log-facility local7;
default-lease-time 600;
max-lease-time 7200;
deny bootp;
ddns-update-style none;
option pcode code 100 = text;
option tcode code 101 = text;
subnet 192.168.9.0 netmask 255.255.255.0 {
range 192.168.9.64 192.168.9.127;
option routers 192.168.9.1;
option domain-name foo;
option domain-name-servers 192.168.5.1;
option ntp-servers 192.168.9.1;
option tcode Europe/Moscow;
}
--
sergio.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Sat, Jul 26, 2014 at 11:43:51PM +0200, Michael Biebl wrote: I think we should do two things: 1/ document in the release notes / systemd FAQ that restarting services from hooks script (ifupdown, dhclient, etc) is problematic. 2/ change invoke-rc.d/service//lib/lsb/init-functions.d/40-systemd to special case (re)start requests while sysinit.target/network.target is scheduled (i.e. during early boot), i.e. use --no-block. This will make systemctl non-blocking and simply enqueue the job. I'm not familiar enough with systemd to comment on your patch. But as a mere user I think such a failsafe might save the day for quite a few people. Bonus point would be to raise some warning about the avoided deadlock, so that users can fix their hooks when needed. With many thanks for your work on this, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 10.07.2014 17:05, schrieb Stefano Zacchiroli:
On Wed, Jul 09, 2014 at 05:31:57PM +0200, Michael Biebl wrote:
So, try to guard your restarts like this:
===
if [ -d /run/systemd/system ]; then
systemctl list-jobs | grep -q network.target exit 0
fi
service shorewall restart
service shorewall6 restart
===
This did the trick! (and I quite like the fact that it will work
properly both with and without systemd running)
I thought about this issue a bit.
It is arguably a bug / configuration error to (re)start a service from a
hook at a point where the dependencies of the service are not yet satisfied.
The resulting dependency loop is silently ignored by sysvinit, which
isn't great.
The failure mode of systemd to simply dead lock isn't great either.
I think we should do two things:
1/ document in the release notes / systemd FAQ that restarting services
from hooks script (ifupdown, dhclient, etc) is problematic.
2/ change invoke-rc.d/service//lib/lsb/init-functions.d/40-systemd to
special case (re)start requests while sysinit.target/network.target is
scheduled (i.e. during early boot), i.e. use --no-block.
This will make systemctl non-blocking and simply enqueue the job.
A sample patch for the lsb init hook is attached
Comments/feedback most welcome.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/init-functions.d/40-systemd b/debian/init-functions.d/40-systemd
index 3260d84..1e6ca11 100644
--- a/debian/init-functions.d/40-systemd
+++ b/debian/init-functions.d/40-systemd
@@ -33,6 +33,7 @@ fi
systemctl_redirect () {
local s
local rc
+local args
local prog=${1##*/}
local command=$2
@@ -53,6 +54,11 @@ systemctl_redirect () {
service=${prog%.sh}.service
+# This is a workaround for users which start services via hook scripts
+# during early boot which can lead to deadlocks.
+if systemctl list-jobs | grep -q -E (network|sysinit)\.target ; then
+args=--no-block
+fi
# Don't try to run masked services. Don't check for errors, if
# this errors, we'll just call systemctl and possibly explode
# there.
@@ -60,7 +66,7 @@ systemctl_redirect () {
[ $state = LoadState=masked ] return 0
[ $command = status ] || log_daemon_msg $s $service
-/bin/systemctl $command $service
+/bin/systemctl $args $command $service
rc=$?
[ $command = status ] || log_end_msg $rc
signature.asc
Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Wed, Jul 09, 2014 at 05:31:57PM +0200, Michael Biebl wrote: So, try to guard your restarts like this: === if [ -d /run/systemd/system ]; then systemctl list-jobs | grep -q network.target exit 0 fi service shorewall restart service shorewall6 restart === This did the trick! (and I quite like the fact that it will work properly both with and without systemd running) Thanks a lot for your guidance, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Thanks for your analysis, it explains what's happening. On Wed, Jul 09, 2014 at 01:18:33AM +0200, Michael Biebl wrote: Am 09.07.2014 01:14, schrieb Michael Biebl: So, what to do about this: I'd say it's a bug to (re)start a SysV init script from an if-up.d hook without actually checking if the service is actually already runnig. Because you simply disregard any dependencies which have been specified in the LSB header. You'd need something like systemd's try-restart, i.e. only restart a service if already running. Something like service shorewall status service shorewall restart should have a similar effect. I've tried this, and it does make the boot complete successfully. However, as a consequence, the shorewall service is not running after boot (because for some reason it fails to properly start the first time), and will never be running again unless I explicitly start it manually (because the test on the left hand side of will always be false). Arguably, this might be a bug in shorewall's init script (that shouldn't fail at boot) or, more likely, due to the fact that shorewall lacks a service description that tells systemd to retry running it later on, when the network is available. If you've any idea/tip about this, I'd appreciate. In the meantime, feel free to deal as you please with this bug. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 09.07.2014 13:51, schrieb Stefano Zacchiroli: I've tried this, and it does make the boot complete successfully. However, as a consequence, the shorewall service is not running after boot (because for some reason it fails to properly start the first time), and will never be running again unless I explicitly start it manually (because the test on the left hand side of will always be false). Arguably, this might be a bug in shorewall's init script (that shouldn't fail at boot) or, more likely, due to the fact that shorewall lacks a service description that tells systemd to retry running it later on, when the network is available. If you've any idea/tip about this, I'd appreciate. What's the output of ls -la /etc/rc?.d/???shorewall and ls -la /etc/rc?.d/???shorewall6 And the output of systemctl status shorewall.service shorewall6.service -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Wed, Jul 09, 2014 at 02:04:49PM +0200, Michael Biebl wrote: What's the output of ls -la /etc/rc?.d/???shorewall and ls -la /etc/rc?.d/???shorewall6 $ ls -la /etc/rc?.d/???shorewall lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc0.d/K01shorewall - ../init.d/shorewall lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc6.d/K01shorewall - ../init.d/shorewall lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rcS.d/S21shorewall - ../init.d/shorewall $ ls -la /etc/rc?.d/???shorewall6 lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc0.d/K01shorewall6 - ../init.d/shorewall6 lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc6.d/K01shorewall6 - ../init.d/shorewall6 lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rcS.d/S21shorewall6 - ../init.d/shorewall6 And the output of systemctl status shorewall.service shorewall6.service $ systemctl status shorewall.service shorewall6.service shorewall.service - LSB: Configure the firewall at boot time Loaded: loaded (/etc/init.d/shorewall) Active: failed (Result: exit-code) since mer 2014-07-09 16:42:17 CEST; 1min 26s ago Process: 1255 ExecStart=/etc/init.d/shorewall start (code=exited, status=1/FAILURE) shorewall6.service - LSB: Configure the firewall at boot time Loaded: loaded (/etc/init.d/shorewall6) Active: active (exited) since mer 2014-07-09 16:43:28 CEST; 15s ago Process: 6089 ExecStop=/etc/init.d/shorewall6 stop (code=exited, status=0/SUCCESS) Process: 6160 ExecStart=/etc/init.d/shorewall6 start (code=exited, status=0/SUCCESS) Note: I'm fine with the fact that shorewall(s) might return a non-0 exit code at boot time, due to the lack of connectivity, but I'd like for the service not to be put in a state where it does not start later on, ever. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 09.07.2014 16:45, schrieb Stefano Zacchiroli: On Wed, Jul 09, 2014 at 02:04:49PM +0200, Michael Biebl wrote: What's the output of ls -la /etc/rc?.d/???shorewall and ls -la /etc/rc?.d/???shorewall6 $ ls -la /etc/rc?.d/???shorewall lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc0.d/K01shorewall - ../init.d/shorewall lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc6.d/K01shorewall - ../init.d/shorewall lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rcS.d/S21shorewall - ../init.d/shorewall $ ls -la /etc/rc?.d/???shorewall6 lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc0.d/K01shorewall6 - ../init.d/shorewall6 lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc6.d/K01shorewall6 - ../init.d/shorewall6 lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rcS.d/S21shorewall6 - ../init.d/shorewall6 And the output of systemctl status shorewall.service shorewall6.service $ systemctl status shorewall.service shorewall6.service shorewall.service - LSB: Configure the firewall at boot time Loaded: loaded (/etc/init.d/shorewall) Active: failed (Result: exit-code) since mer 2014-07-09 16:42:17 CEST; 1min 26s ago Process: 1255 ExecStart=/etc/init.d/shorewall start (code=exited, status=1/FAILURE) shorewall6.service - LSB: Configure the firewall at boot time Loaded: loaded (/etc/init.d/shorewall6) Active: active (exited) since mer 2014-07-09 16:43:28 CEST; 15s ago Process: 6089 ExecStop=/etc/init.d/shorewall6 stop (code=exited, status=0/SUCCESS) Process: 6160 ExecStart=/etc/init.d/shorewall6 start (code=exited, status=0/SUCCESS) Note: I'm fine with the fact that shorewall(s) might return a non-0 exit code at boot time, due to the lack of connectivity, but I'd like for the service not to be put in a state where it does not start later on, ever. That is a bit odd. The SysV should only be run once the networking service init script has started. The problem most likely here is, that you use allow-hotplug. You'd need something like [1] which actively blocks until you actually have a network connection. Anyway, since apparently your shorewall.service is *not* successfully started during boot, the service shorewall status service shorewall restart workaround will indeed not work. In that case you could apply the same workaround that was done for the mountnfs hook, i.e. do not trigger a restart of the shorewall service while the networking init script is still being started, i.e. network.target job is currently being scheduled and not yet running. So, try to guard your restarts like this: === if [ -d /run/systemd/system ]; then systemctl list-jobs | grep -q network.target exit 0 fi service shorewall restart service shorewall6 restart === [1] http://people.debian.org/~biebl/ifupdown-wait-online.tar.gz -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Package: systemd
Version: 204-14
Severity: serious
I've rebooted today my laptop (Debian testing) and it failed to boot, hanging
forever on the message:
[ *** ] A start job is running for LSB: Raise network interfaces.
with the 3 asterisks moving back and forth.
I've been using systemd-sysv since several months now, and this is the first
time I've stumbled upon this (even though I do not boot that often, on average
every 2 weeks or so).
I've tried various workarounds (including /etc/network/interfaces) but the only
actual solution I've found it to manually remove systemd-sysv, install back
systemd-shim and sysvinit{,-core}; with that the laptop boots again. If I now
manually try to boot using systemd (passing init=/bin/systemd directly to the
kernel command line), the boot hangs again.
Note that I went through #746358 (boot hangs if /etc/fstab contains an NFS
mount) and it does *not* appear to be the same issue. For one thing I do not
have any NFS entry in /etc/fstab (the closest I have is an autofs entry);
additionally, the fix discussed on the bug report *is* present on my laptop, to
no avail.
I attach both /etc/fstab and /etc/network/interfaces, hoping they are useful.
Thanks for maintaining systemd in Debian, systemctl status is so cool that I
can't wait to get it back on my laptop :)
Cheers.
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd depends on:
ii acl 2.2.52-1
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-53.2
ii libacl1 2.2.52-1
ii libaudit11:2.3.7-1
ii libc62.19-4
ii libcap2 1:2.22-1.2
ii libcap2-bin 1:2.22-1.2
ii libcryptsetup4 2:1.6.4-4
ii libdbus-1-3 1.8.6-1
ii libgcrypt11 1.5.3-4
ii libkmod2 16-2
ii liblzma5 5.1.1alpha+20120614-2
ii libpam0g 1.1.8-3
ii libselinux1 2.3-1
ii libsystemd-daemon0 204-14
ii libsystemd-journal0 204-14
ii libsystemd-login0204-14
ii libudev1 204-14
ii libwrap0 7.6.q-25
ii sysv-rc 2.88dsf-53.2
ii udev 204-14
ii util-linux 2.20.1-5.8
Versions of packages systemd recommends:
ii libpam-systemd 204-14
Versions of packages systemd suggests:
pn systemd-ui none
-- no debconf information
0 overridden configuration files found.
==
/var/lib/systemd/deb-systemd-helper-enabled/sysinit.target.wants/plymouth-read-write.service
==
==
/var/lib/systemd/deb-systemd-helper-enabled/sysinit.target.wants/plymouth-start.service
==
==
/var/lib/systemd/deb-systemd-helper-enabled/lvm2-activation.service.dsh-also ==
/etc/systemd/system/local-fs.target.wants/lvm2-activation.service
==
/var/lib/systemd/deb-systemd-helper-enabled/bluetooth.target.wants/bluetooth.service
==
== /var/lib/systemd/deb-systemd-helper-enabled/puppetmaster.service.dsh-also
==
/etc/systemd/system/multi-user.target.wants/puppetmaster.service
==
/var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.ModemManager1.service
==
== /var/lib/systemd/deb-systemd-helper-enabled/sshd.service ==
== /var/lib/systemd/deb-systemd-helper-enabled/bluetooth.service.dsh-also ==
/etc/systemd/system/bluetooth.target.wants/bluetooth.service
/etc/systemd/system/dbus-org.bluez.service
==
/var/lib/systemd/deb-systemd-helper-enabled/kexec.target.wants/plymouth-kexec.service
==
==
/var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-wait-online.service.dsh-also
==
/etc/systemd/system/multi-user.target.wants/NetworkManager-wait-online.service
== /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.socket.dsh-also ==
/etc/systemd/system/sockets.target.wants/avahi-daemon.socket
==
/var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/lvm2-lvmetad.socket
==
==
/var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/cups.socket ==
==
/var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/avahi-daemon.socket
==
==
/var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/acpi-fakekey.socket
==
==
/var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.Avahi.service
==
==
/var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.NetworkManager.service
==
== /var/lib/systemd/deb-systemd-helper-enabled/plymouth-kexec.service.dsh-also
==
/etc/systemd/system/kexec.target.wants/plymouth-kexec.service
== /var/lib/systemd/deb-systemd-helper-enabled/plymouth.service ==
== /var/lib/systemd/deb-systemd-helper-enabled/syslog.service ==
==
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/puppet.service
==
==
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 08.07.2014 21:20, schrieb Stefano Zacchiroli: Package: systemd Version: 204-14 Severity: serious I've rebooted today my laptop (Debian testing) and it failed to boot, hanging forever on the message: [ *** ] A start job is running for LSB: Raise network interfaces. Did you actually wait forever, i.e. at least 90 seconds which is the usual timeout for devices to appear or services to start? Can you please try the following: systemctl enable debug-shell.service This allows you to switch to tty9 very early during boot and inspect the system. A systemctl list-jobs and ps aux output might be helpful in this case. Booting with systemd.log_level=debug and the journalctl -alb output would be great as well. Could you also please tar up /etc/network/interfaces, /etc/network/*, /etc/dhcp*, /etc/rc?.d/ and /etc/init.d. This might give us further clues. Thanks and sorry for the inconvenience. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Tue, Jul 08, 2014 at 09:32:43PM +0200, Michael Biebl wrote: Did you actually wait forever, i.e. at least 90 seconds which is the usual timeout for devices to appear or services to start? Obviously I didn't wait *forever* :), but yes, I did wait past usual network timeouts. To be sure, I've just tried again, and after 10+ minutes the boot was still hanging. The good news is... Can you please try the following: systemctl enable debug-shell.service ...thanks to this, which I didn't know about, I've tracked down the culprit to my /etc/network/if-up.d/local-firewall script, which reads: #!/bin/sh # This file is managed by Puppet, local modifications will be overwritten FIREWALL=shorewall FIREWALL6=shorewall6 service $FIREWALL restart service $FIREWALL6 restart After a couple of killall local-firewall (one for each service invocation, evidently) the boot continued and reached completion properly. A systemctl list-jobs and ps aux output might be helpful in this case. Both attached, just in case, but the cause seems to be clear. Now the questions/comments: - I've had that script since ever, basically, and it used to work fine in the past, both before and after switching to systemd as init. I'm not sure why/when it stopped working. - As a mere user, the above script is perfectly reasonable, I *do* want to restart my firewall every time my network interface is brought up, and AFAICT I'm using the right API to do so. HTH, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » 1 graphical.target start waiting 2 multi-user.targetstart waiting 3 basic.target start waiting 4 sysinit.target start waiting 64 networking.service start running 65 network.target start waiting 67 rpcbind.service start waiting 68 rpcbind.target start waiting 71 shorewall.servicestart waiting 73 shorewall6.service start waiting 74 nfs-common.service start waiting 77 sockets.target start waiting 79 cups.socket start waiting 80 acpid.socket start waiting 81 avahi-daemon.socket start waiting 82 acpi-fakekey.socket start waiting 85 dbus.socket start waiting 86 timers.targetstart waiting 87 systemd-tmpfiles-clean.timer start waiting 88 paths.target start waiting 89 console-kit-log-system-start.service start waiting 90 uptimed.service start waiting 91 avahi-daemon.service start waiting 92 atd.service start waiting 93 binfmt-support.service start waiting 94 cups.pathstart waiting 97 cups-browsed.service start waiting 98 cups.service start waiting 99 ModemManager.service start waiting 100 plymouth-quit-wait.service start waiting 101 ssh.service start waiting 102 NetworkManager.service start waiting 103 cron.service start waiting 104 privoxy.service start waiting 105 plymouth-quit.servicestart waiting 106 anacron.service start waiting 107 rsyslog.service start waiting 110 rc-local.service start waiting 111 systemd-user-sessions.servicestart waiting 113 getty.target start waiting 114 getty@tty1.service start waiting 115 dbus.service start waiting 116 systemd-logind.service start waiting 117 systemd-update-utmp-runlevel.service start waiting 118 speech-dispatcher.servicestart waiting 119 gdomap.service start waiting 120 puppetqd.service start waiting 121 gdm3.service start waiting 122 x-display-manager.target start waiting 123 acpi-support.service start waiting 124 bootlogs.service start waiting 125 apache2.service start waiting 126 sysfsutils.service start waiting 127 ntp.service start waiting 128 dictd.servicestart waiting 129 minissdpd.servicestart waiting 130
Bug#754218: boot hangs forever on LSB job raise network interfaces
On Tue, Jul 08, 2014 at 10:50:27PM +0200, Stefano Zacchiroli wrote: #!/bin/sh [...] service $FIREWALL restart service $FIREWALL6 restart After a couple of killall local-firewall (one for each service invocation, evidently) the boot continued and reached completion properly. Actually, that doesn't make sense. Because of course either the first killall has killed the script and the second service is not executed; or it didn't, but then why the second did? So I'm still unsure about why the killall(s) made the boot complete successfully. If this detail is important, please let me know; I can debug it more thoroughly (e.g., by noting down PIDs). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 08.07.2014 22:50, schrieb Stefano Zacchiroli: Now the questions/comments: - I've had that script since ever, basically, and it used to work fine in the past, both before and after switching to systemd as init. I'm not sure why/when it stopped working. - As a mere user, the above script is perfectly reasonable, I *do* want to restart my firewall every time my network interface is brought up, and AFAICT I'm using the right API to do so. I had a look at the shorewall(6) init script. It has # Required-Start:$network $remote_fs Now, $network is provided by the networking init script. As long as this init script is not fully started, $network (or network.target) is not yet available. You've started shorewall as part of the if-up up, when $network is not yet available, thus there is a dead lock. So, it's actually exactly the same problem as with the NFS hook. sysvinit doesn't bother, as it doesn't consider such dynamic dependencies during runtime whereas systemd does. What has changed is, that systemd_204-9 gained support for LSB system facilities, i.e. now it understands that /etc/init.d/networking provides $network. This is most likely the reason you didn't see it in the past. So, what to do about this: I'd say it's a bug to (re)start a SysV init script from an if-up.d hook without actually checking if the service is actually already runnig. Because you simply disregard any dependencies which have been specified in the LSB header. It's problematic in general to (re)start SysV init scripts from any hook (if-up.d, dhcp etc), since you can't ensure at that point that its dependencies are actually all available. I personally would consider this a local (mis)configuration which simply didn't show up with sysvinit which only computes dependencies at install time and only between init scripts in /etc/rc?.d/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 09.07.2014 01:14, schrieb Michael Biebl: So, what to do about this: I'd say it's a bug to (re)start a SysV init script from an if-up.d hook without actually checking if the service is actually already runnig. Because you simply disregard any dependencies which have been specified in the LSB header. You'd need something like systemd's try-restart, i.e. only restart a service if already running. Something like service shorewall status service shorewall restart should have a similar effect. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 09.07.2014 01:14, schrieb Michael Biebl: Am 08.07.2014 22:50, schrieb Stefano Zacchiroli: Now the questions/comments: - I've had that script since ever, basically, and it used to work fine in the past, both before and after switching to systemd as init. I'm not sure why/when it stopped working. - As a mere user, the above script is perfectly reasonable, I *do* want to restart my firewall every time my network interface is brought up, and AFAICT I'm using the right API to do so. Running within the context of an if-up.d hook you make an explicit assumption that $network is already provided, which is probably reasonable. Strictly speaking though, the LSB $network facility is defined in /etc/insserv.conf when the networking (or the old ifupdown) SysV init script has been fully started, which is not the case during the inital start of that script. I'm not sure how to address this. Either the hooks are fixed to not make this assumption, or the bring network up phase proving $network and run if-up.d hooks are split into two different SysV init scripts. The latter is probably not feasable. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754218: boot hangs forever on LSB job raise network interfaces
Am 09.07.2014 01:28, schrieb Michael Biebl: Running within the context of an if-up.d hook you make an explicit assumption that $network is already provided, which is probably reasonable. Strictly speaking though, the LSB $network facility is defined in /etc/insserv.conf when the networking (or the old ifupdown) SysV init script has been fully started, which is not the case during the inital start of that script. I'm not sure how to address this. Either the hooks are fixed to not make this assumption, or the bring network up phase proving $network and run if-up.d hooks are split into two different SysV init scripts. The latter is probably not feasable. And it doesn't address the issue that the service which is (re)started from the hook has other dependencies. Say the shorewall service has other dependencies like e.g. mysql, because it stores its rules there (yeah, I made that up :-) ). If you now restart shorewall from the if-up.d hook it will be started during rcS (i.e. early boot) completely disregarding the dependency on mysql. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
