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

5
  • Do you have multiple gateway statements in your /etc/network/interfaces file? Have a look at this: serverfault.com/questions/382279/… Feb 18, 2016 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, 2016 at 21:29
  • @Bouki, without looking at the content of /etc/network/interfaces file, it would be difficult to comment I guess.
    – Diamond
    Feb 19, 2016 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, 2016 at 10:15
  • I have 128gb of ram, only 5% used at boot, and 20% at max
    – Bouki
    Feb 19, 2016 at 13:53

1 Answer 1

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

4
  • 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, 2016 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, 2016 at 5:23
  • yes tried it but no changes
    – Bouki
    Feb 25, 2016 at 9:12
  • @Bouki did you get any additional information from the enabling the debug shell?
    – sippybear
    Feb 25, 2016 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .