[systemd-devel] /etc/systemd/system/darkice.service

[Colin Guthrie]

'Twas brillig, and Kai Hendry at 25/07/13 06:22 did gyre and gimble:
> Going back to the timeout, I started the PI without a network. Waited
> a minute or two. Then I started pingtest.service manually. I was
> surprised that network-online.target doesn't turn active. I had to
> manually start it.
> http://ix.io/6RD

These targets are effectively static synchronisation points. The problem
here is that you're trying to map a very dynamic concept (networks
coming and going) to a static one (targets being reached).

You could turn such a thing into something more dynamic by writing a
deamon which actively monitors the network status and starts/stop the
network-online.target accordingly. Service units could then Requires
network online and be automatically stopped when it was stopped.

But this creates a lot more problems. Units would have to be changed to
have WantedBy=network-online.target (as opposed to the more common
multi-user.target) and to also have a Requires=network-online.target as
mentioned above.

This seems like it might be good at first, but the problem is you lose
all state information.

If you stop several enabled services manually (and deliberately) then at
some point later the network has a blip and the target is stopped
(stopping all services that require it) but then comes back again, then
*all* enabled services will be started again, including the ones
manually stopped by the administrator.

There are several other problems that arises here too. Such as the
definition of what "network up" actually is. Different daemons work on
different definitions and thus we'd have to have a whole bunch of
targets with fine-grained names to capture all the combinations and have
monitoring daemons for each.

Then there are some services that only care about one interface working,
not the whole network so you need targets and monitors for that too.
Some daemons only want a local network and not a public internet so you
add another factor to the combinations with that too. Before long (and
long before this point) it becomes obvious the whole things is just
totally unmanageable like this.


Really the "network-online.target" is just a hack. It represents a "best
effort" point in time that was also provided (equally badly) by previous
init systems.

The only *real* way to fix this problem is for the daemons themselves to
properly deal with networks coming and going. Only the daemons with
their config files can know what is important to them, which interfaces
matter, whether an external network is needed or whether this is a
purely local one etc. etc. The services themselves need to behave
properly in a dynamic environment and not assume it's static.

See the "What does this mean for me, a Developer?" section on this page
which basically says exactly this:
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Hope this explains it to you a little.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/