[systemd-devel] network consuming user services
lennart at poettering.net
Wed May 2 17:11:16 PDT 2012
On Wed, 02.05.12 16:53, David Strauss (david at davidstrauss.net) wrote:
> On Wed, May 2, 2012 at 3:58 PM, Lennart Poettering
> <lennart at poettering.net> 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
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
Hence: network.target should only be used for software which is
incapable of listening to netlink, or using IP_FREEBIND.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel