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

[Dan Tihelka]

Hello,
thank you for such a long and detailed answer. I do agree with you in general.

Of course, there is an intersection of two words. On one side there is an init 
daemon being responsible for starting/stopping services. On the second side 
there is an network management system/daemon handling the net connection. And 
as it is true that init daemon does not have to handle network status (as you 
explained), a network manager does not have to start services ...

The way (well, you may have a better solution, probably ...) is in 
communication. I can imagine that the network manager will emit dbus broadcast 
messages about network up/down, no matter what particularly it means (there 
may even be several different kinds of signals). If init daemon can handle the 
dbus signals, users or admins can write services as the reactions to them. 

And here I don't mean any "standardized" set of signals which both systems 
have to implement. It is enough to allow StartOnDBus="user-write-what-
require", SopOnDBus="user-write-what-require" and similar stuff. Similarly to 
sockets activation or automounting capability.

Do you think that it is the way, or am I completely mistaken?

Thank you,
Dan

P.S.I think it could possibly be achieved through files as well, using 
systemd.path (although it not as elegant). I am not sure about stopping the 
service, however ...	



On Monday 15 of October 2012 17:51:18 Lennart Poettering wrote:
> 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