I just made some new tests. It seems the issue appears less often then before (where it failed in like 9 out of 10 boots),... this time it's more like failure in 3 of 4 boots. But there was a new kernel, and maybe that somehow changed some timing issues?
Anyway, attached is a new log files from the network-restarter.log.2, I've also changed /etc/init.d/networking a bit more (even during the runs) to give more debug output, so I'm attaching that as well All the tests here were run with allow-auto eth0. I've added a 2nd ifup in /etc/init.d/networking, so there is no one that starts "immediately" after the init script is run, then there is a sleep of 30 seconds and then there is another ifup. All of them are surrounded by outputting ifconfig to the network-restarter.log.2. In the last run, I've also added outputting the exit codes of ifup. In the log I've added a bunch of more newlines between reboots. What one can basically see, especially at the last run, is: - lo is already up before /etc/init.d/networking,... well I guess systemd is taking care on this before? - It happens (actually more often then you'd guess from that log excerpt of my tests - as I've said roughly 3 out of 4 times now), that after the first ifup (i.e. before any sleep) no further interfaces are brought up... In these tests, eth0 always came up at least after the 2nd ifup, this is why my cron job never had to kick in (and I didn't even include the output of that, i.e. what I've called network-restarter.log before). - when ifup fails to bring up the interface, it doesn't even tell so via it's exit status. Which kinda emphasizes the suspicion that this is an issue in ifupdown. This and also the problem that *even* when the interface *was* brought up, it still seems to happen that daemons cannot yet bind to their addresses....? Cheers, Chris.
networking
Description: application/shellscript
network-restarter.log.2.xz
Description: application/xz
smime.p7s
Description: S/MIME cryptographic signature
