Sergio Gelato <[email protected]> writes: > After rebooting one of my OpenAFS servers (that was set up to acquire > its IP address through DHCP) I found (reproducibly, on that particular > server) that all BOS-controlled services ended up being stopped after > too many failures to start. Running "bos start localhost <instance> > -localauth" was enough to recover.
> A look at the logs convinced me that the services failed because they > were trying to start before the server had an IP address. Switching to a > static configuration in /etc/network/interfaces has cured the problem. > /etc/init.d/openafs-fileserver, which starts bosserver, has a > Required-Start: $remote_fs $network $time $named > and /etc/insserv.conf defines $network as "+networking +ifupdown". > /etc/init.d/networking runs "ifup -a". Apparently this can return > before the interface(s) is(are) actually usable. > Is this bosserver's or ifup's fault? This isn't entirely clear to me (and > I see there is a five-year-old important bug against ifupdown, #418326, > which also touches on whether "ifup -a" should wait until the interfaces > are fully up) but I suspect it may be unrealistic to make "ifup -a" > block for too long waiting on an interface. I think ifup -a should block until the interfaces are actually up, since otherwise there's really no way to rely on the $network dependency to mean anything, and that dependency is there precisely so that software which requires the network can not start until the network is actually there. So I'd be inclined to say that this is a bug in ifup -a. That said, I'd be happy to fix it in OpenAFS anyway, except that... > Pragmatically, then, one would like for bosserver to make a fresh > attempt at starting these services whenever an interface becomes ready. ...this is rather tricky to do. Getting the list of configured local interfaces so that you know when it changes is rather non-portable and hard to do properly and reliably. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
