'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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel