Boot stuck when network is down
Hello, fellow users!
Firstly, a question about questions; is it ok to ask although I'm
reading the digest? Should I be subscribing to the actual list instead?
Now to my real issue: last night there was some sort of temporary glitch
in our network, during which I tried rebooting when I thought it was a
problem with my system (I'm running up-to-date Sarge). When the OS was
booting, it first got stuck with running ntpdate, as the network
apparently was still down (or maybe it was just the dns, don't know). I
was able to continue booting by pressing ctrl+c, but then it went on to
starting the MTA (exim), and again was stuck. Ctrl+c didn't help this
time, nor did any other keys or combinations I tried. I assume it was
trying to use the network and was waiting for something, seemingly
forever (although I can't be sure). I used the reset button on my
computer and switched to Windows at that point - the network had
apparently begun working during the switch and when I came back to
Debian, the boot went flawlessly.
So here's the question: is it normal and/or acceptable for
network-depending processes to stall the whole boot process when they're
unable to access the network - I mean, is there maybe some sort of
security/priority/whatever reason why there's no testing if the app is
waiting for something for too long and send an interrupt to it or leave
it in the background and let the booting continue? Or is there a key (or
a combination) for the user to do this manually which I'm unaware of?
I was unable to google anything useful about this.
I once used SuSE Linux and I remember that during the boot, when
fetching IP address using dhcp, if it decided that it was taking too
long to finish, it would leave it in the background and continue with
the rest of the booting. It's something along those lines I'm thinking here.
Reply to: