2

I have a fresh install of debian 8.3 jessie on a new server with all upgrades

However each time I try to reboot the machine, debian enter in emergency mode

The screen got stucked at "A start job is running for LSB: Raise network interfaces"

With the original /etc/network/interfaces (containing 1 IPv4 & IPv6) the boot takes 2min30, 99% due to networking.service (checked with systemd-analyze blame), everything else takes less than 200ms

However the real /etc/network/interfaces has 100+ IPs and with this config file the server cannot boot at all, even after being online a few hours

I also have to mention that when I boot on a minimal /etc/network/interfaces and I replace the file with the correct one and restart network, everything is fine (takes 20min but at least it works)

I don't have a clue of what's going on here is what journalctl -b -u networking.service returns :

Feb 15 00:09:38 systemd[1]: Starting LSB: Raise network interfaces....
Feb 15 00:09:48 networking[691]: Configuring network interfaces...RTNETLINK answers: File exists
Feb 15 00:09:48 networking[691]: RTNETLINK answers: File exists
Feb 15 00:09:50 networking[691]: Waiting for DAD... Done
Feb 15 00:09:50 networking[691]: RTNETLINK answers: File exists
Feb 15 00:09:50 networking[691]: Failed to bring up eth0.
Feb 15 00:09:55 networking[691]: RTNETLINK answers: File exists
Feb 15 00:09:55 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:00 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:00 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:06 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:06 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:09 ntpdate[1009]: 37.187.98.51 rate limit response from server.
Feb 15 00:10:11 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:11 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:16 ntpdate[1059]: 130.236.254.17 rate limit response from server.
Feb 15 00:10:16 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:16 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:18 ntpdate[1009]: step time server 213.251.128.249 offset -0.100865 sec
Feb 15 00:10:21 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:21 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:23 ntpdate[1059]: step time server 213.251.128.249 offset -0.100906 sec
Feb 15 00:10:26 ntpdate[1155]: 130.236.254.17 rate limit response from server.

Any help will be really appreciated

Regards

  • Do you have multiple gateway statements in your /etc/network/interfaces file? Have a look at this: serverfault.com/questions/382279/… – Guido Vaccarella Feb 18 '16 at 21:12
  • I only have 1 gateway, and it doesn't explain why the boot is so slow even with 1 IP – Bouki Feb 18 '16 at 21:29
  • @Bouki, without looking at the content of /etc/network/interfaces file, it would be difficult to comment I guess. – Diamant Feb 19 '16 at 8:50
  • here are my file, the first one prevent booting, the second allow booting but very very slow gist.github.com/Bouki/17ac05f1d8cdb0fbcb75 – Bouki Feb 19 '16 at 10:15
  • I have 128gb of ram, only 5% used at boot, and 20% at max – Bouki Feb 19 '16 at 13:53
3
+50

This bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218 seems pretty relevant. The user describes a similar issue where his system hangs displaying "A start job is running for LSB: Raise network interfaces" message.

They use the following steps to identify the cause of the issue:

  1. Enable the debug shell:
    • systemctl enable debug-shell.service
  2. Restart the system.
  3. Debug messages reveal the cause of the problem to be:
    • /etc/network/if-up.d/local-firewall

This user was using shorewall, but several other users report similar issues with different firewalls later in the thread. If the debug session reveals your firewall initialization to be the issue, these steps may resolve the issue:

  1. To complete the boot, the user had to use the killall command several times:
    • killall local-firewall
  2. Once the OS was loaded, the user edited /etc/network/if-up.d/local-firewall script from:

    #!/bin/sh
    FIREWALL=shorewall
    FIREWALL6=shorewall6
    
    service $FIREWALL restart
    service $FIREWALL6 restart
    

    to:

    #!/bin/sh
    if [ -d /run/systemd/system ]; then
           systemctl list-jobs | grep -q network.target && exit 0
    fi
    service shorewall restart
    service shorewall6 restart
    

This modification resolves the issue because the "if" condition allows the firewall initialization to wait until after the NIC is fully initialized, allowing several environment variables that the firewall depends on to be populated.

If you are not using a local firewall, there is another similar bug report but the issue is caused by NFS mounts during boot. If that is closer to your environment, this may prove of interest: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746358

  • thank you for your answer, however I don't have shorewall or shorewall6 installed but I do have a NFS mount, I'll try the fix – Bouki Feb 20 '16 at 18:40
  • @Bouki did you try commenting out your NFS mounts from /etc/fstab? If so, did it have any effect? – sippybear Feb 25 '16 at 5:23
  • yes tried it but no changes – Bouki Feb 25 '16 at 9:12
  • @Bouki did you get any additional information from the enabling the debug shell? – sippybear Feb 25 '16 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.