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

Bouki
  • 115
  • 1
  • 3
  • 11
  • Do you have multiple gateway statements in your /etc/network/interfaces file? Have a look at this: http://serverfault.com/questions/382279/added-eth00-configuration-but-fails-on-ifup-with-rtnetlink-answers-file-exist – 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. – Diamond Feb 19 '16 at 08:50
  • here are my file, the first one prevent booting, the second allow booting but very very slow https://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

1 Answers1

3

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

sippybear
  • 2,997
  • 1
  • 12
  • 12