On Wed, 02.05.12 16:53, David Strauss ([email protected]) wrote: > > On Wed, May 2, 2012 at 3:58 PM, Lennart Poettering > <[email protected]> wrote: > > But if you want that you can do that simply by enabling > > NetworkManager-wait-online.service, which then delays > > network.target accordingly. > > That would work, but it has potential undesirable effects: > > * Any services associated with network.target will wait longer to > start, even if all they need to do is bind to *:80. This reduces > parallelism.
They shouldn't wait for network.target then. > * If NetworkManager-wait-online.service causes network.target to only > fire once all interfaces are up, a service like openssh-server might > not start if only one of the interfaces comes up. This occasionally > happens on multihomed systems where only the public or private > interface comes up. It would be annoying to not have SSH access in > such a situation. Same here, SSH should not be delayed after network.target. > * It's not clear when or how network.target gets "stopped." If > network.target stops on loss of any interface, existing services might > flap unnecessarily. It would be bad to have MySQL, for example, stop > or restart because a switch restarted. If network.target never gets > stopped or only gets stopped on total network shutdown (no 127.0.0.1), > it would not solve Sebastian's use case. His use case requires > stopping certain network-dependent services when links go down. network.target isn't really something that should be removed. I mean, you can spend a lot of braincells on defining precise semantics for network.target, but in the end I think it's all pointless, since we know that different apps understand different things under "network is around", and in a dynamic and multi-homed network such a definition is broken anyway... Hence: network.target should only be used for software which is incapable of listening to netlink, or using IP_FREEBIND. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
