On Tue, 10.05.11 00:23, Miloslav TrmaÄ (mitr@xxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
