[systemd-devel] Starting/stopping service on net connection

[Lennart Poettering]

On Sun, 14.10.12 16:15, Dan Tihelka (dtihelka at gmail.com) wrote:

> Hallo,
> just a short question, sorry if it seems "stupid", I am just curious. And 
> google does not provide satisfactory answers (or I didn't ask the right 
> question)
> 
> So:
> is there a robust and reliable way of starting/stopping a service  when a net 
> connection is established/lost? And I mean also the case where a cable is 
> disconnected (or wifi signal lost), which should be detected by NetworkManager 
> (or an alternative daemon).

We do not offer any special support for something like this in systemd
itself.

This has various reasons:

a) in general we can only recommend to update networking daemons that
assume a fixed, and continous network link to exist so that they handle
with changing networks better. Today's networks aren't like they used to
be. Network links break and come back online, and configuration changes
all the time. This is true for client systems, but also very much for
servers. Software that assumes networking was static doesn't reflect how
things work these days. The kernel has offered APIs for subscribing to
network configuration changes for a long time ("rtnetlink"), and network
services really should make use of this, and many already do (for
example bind has been subscribing to netlink changes since a long long
time).

b) There are varying definition what "network is up" means. Some
interfaces might be required, others not. Some people probably assume
that "up" means that the iface is around, others believe "up" means that
there was a link beat, others assume it means "IPv4 address is
configured", others assume it means "IPv6 address is configured", even
others "IPv4 AND IPv6 is configured", even others "IPv4 OR IPv6 is
configured", even others "A certain host is reachable" and so on. In
systemd we'd really like to avoid this discussion for as long as we can,
especially as we really want to stay away from turning systemd into a
monitoring system.

c) We generally believe that system boot-up should not be affected by
whether network is around or not. You system should not fail to boot or
become slow at boot, just because somebody tripped over a network
cable. Systems should be robust, and simple, and make the best on what
is available, instead of requiring any resources to be strictly available. 

So, for all of this and more, we currently offer no high-level hooks in
systemd itself for "waiting for network". That said, We expect that
admins/other software adds meaning to network.target, the way he
wants. network.target however is very simplistic and static, as it
cannot react to network configuration changes. It is hence primarily
useful for systems which are "static" enough, or which are file system
clients to a specific network.

Other than that the various networking management services tend to have
call-out dirs that can be used to start/restart/stop services on certain
events. It is relatively easy to stick scripts into those. However, be
aware of ordering cycles this might create: i.e. if a service
foobar.service wants to be started after network.target, but a service
that implements networking actually wants to start foobar.service at
initializuation and waits for this to complete will result in a deadlock
(simply because foobar.service is both supposed to finish starting before
AND after network.target that way, which is contradicting). A way to
avoid such cycles is via --no-block on the systemctl cmdline.

Or in short: you probably want to rely on hooks of other software,
systemd alone won't solve this for you.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.