informations about boot sequence (Re: F15 - mysql start problem)

[Lennart Poettering]

On Tue, 10.05.11 00:23, Miloslav Trmač (mitr at volny.cz) wrote:

> I can't see that.  If I configure a server to listen on 192.168.1.1,
> and my IP address changes to 192.168.1.2 for whatever reason, how will
> I ever be notified that the configuration is incorrect? By a log entry
> in syslog?

If a local IP address becomes unavailable that a socket is bound to this
has no effect on the socket itself, regardless whether IP_FREEBIND is
used or not. i.e. if you managed to bind the socket once, it will stay
bound for good; hence there is not really a difference in this regard.

> * If an user logs in before the server starts, service status will be
> reported as "pending" - which is correct
> * After the network is up, the server can bind normally (without
> relying on Linux-specific features).
> * If the bind() fails, the server aborts and the service status will
> be reported as "failed" - which is correct, and the obvious place to
> check in case of problems.

I think a robust system, regardless whether laptop or server should be
as independent from the network as possible. That means it should
provide its services under all circumstances, so that local clients can
access it always, and remote services under all circumstances when the
network is up. I think it is good design if your machine boots up no
matter what, whether your ethernet cable is plugged or not, or whether
your antenna broke, and it should always work as well as it can.

If you hook into netlink changes then you can implement a fully robust
server, and some servers work like this, for example bind. Using netlink
is a very powerful tool but also not a one-line change in your server. A
simpler solution is IP_FREEBIND or binding only to 0.0.0.0 (i.e. all
local IP addresses). Or even combining 0.0.0.0 with SO_BINDTODEVICE to
bind things by device instead of IP address.

It's a simple fact that we live in a dynamic world these days. Hardware
configuration changes, network configuration changes, all the time. We
should write our software to deal with this as well as possible, and
keep the dependencies we need to run at a minimum. That means that MySQL
should not be delayed until the network is fully up, until a DHCP server
replied. You want it run quickly, and then make the best of the network
as it shows up, or as it goes away again, and even if it later returns.

> Is the tradeoff really "correctness vs. saving a few seconds when
> booting a server"?

There is not really a tradeoff here. I think everybody wins if we make
our systems robust, by not unnecessarily slowing down/allowing to hang
our boot if external services like the network are not up.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.