On Tue, May 10, 2011 at 12:05 AM, Adam Williamson <awilliam@xxxxxxxxxx> wrote:
> You could have them wait for the network to be available simply by
> setting them to depend on NetworkManager-wait-online.service: but that's
> not a very good solution to anyone's problem. It's far better for them
> to be able to start up before a network connection is available, and
> then start working when one is available. It makes startup faster and
> makes the servers in question more robust.
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?
It seems much more practical to me to set up such network-facing
servers (which are not necessary for local user login) to only start
after the network is available:
* 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.
* On desktops nobody really cares how soon postgresql starts - being
able to log quickly in is more important.
* On servers with statically configured IP addresses, is the delay
caused by NM-wait-online noticeable?
* On systems that depend on DHCP, depending on NM-wait-online is
necessary for reliable error detection.
Is the tradeoff really "correctness vs. saving a few seconds when
booting a server"?
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
