Bug 879370

Above and beyond how you get the network information *into * systemd so you can calculate the dependnecy, the problem I see there is 'wired, but connected to a crappy hotel internet', or 'wifi is normally fine, but not if I'm connected to my mobile hotspot'.

True, but we can go with some reasonable defaults and leave a checkbox for each connection that would say 'Minimize maintenance traffic through this network.' or something.

Managing network connectivity in systems isn't really an option. That's something we cannot win.

In general we expect people to give network.target the meaning they wish. With that in place you can then do stuff like Requisite=network.target in your units, and the unit won't run if the target is not around.

(In reply to comment #3)
> Managing network connectivity in systems isn't really an option. That's
> something we cannot win.
> 

That sounds very categorical, and it is twisting the reality into turning my reasonable proposal into something that looks undoable. Which is not the case.

(In reply to comment #3)
> In general we expect people to give network.target the meaning they wish.
> With that in place you can then do stuff like Requisite=network.target in
> your units, and the unit won't run if the target is not around.

This should work. One can represent any number of useful service levels by a bunch of dummy targets that would be started/stopped by NetworkManager or what have you. Nothing needs to be special-cased in systemd.

It has one disadvantage. If the requisite unit is inactive, the timer will still fire, only to find out that nothing needs to be done at this moment. One could get around this by starting/stopping the timer unit itself at appropriate times, but this could be messy. A new directive could make it easier:
TriggerRequisite=<unit name>

(In reply to comment #5)
> A new directive could make it easier:
> TriggerRequisite=<unit name>

Thinking about this some more... Then of course there would be questions about how exactly should the time be counted while this unit is inactive. Should the "ticking" of the timer be stopped while the unit is inactive? Or should the timer fire as soon as the unit goes active if sufficient time elapsed? Or should it behave as if the timer were ticking all along?
Coming to questions like this makes me throw away the TriggerRequisite idea.

(In reply to comment #5)
> This should work. One can represent any number of useful service levels by a
> bunch of dummy targets that would be started/stopped by NetworkManager or
> what have you. Nothing needs to be special-cased in systemd.
> 

Hmm, actually now when I get it I kind of like it.

> It has one disadvantage. If the requisite unit is inactive, the timer will
> still fire, only to find out that nothing needs to be done at this moment.

Is that really a problem? That's not much work for the timer to do, or is it?

(In reply to comment #7)
> Is that really a problem?

No.

(In reply to comment #4)
> (In reply to comment #3)
> > Managing network connectivity in systems isn't really an option. That's
> > something we cannot win.
> > 
> 
> That sounds very categorical, and it is twisting the reality into turning my
> reasonable proposal into something that looks undoable. Which is not the
> case.

Well, I think it's nothing we should do in systemd. I mean, I am not doubting the use-case, but I am pretty convinced, that we should not try to come up with a definition in systemd of what it means that the network is up, and then expose that as primary configuration option.

Regarding the weak definition of "network is up":

http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

Opened NetworkManager bug 896572 for the dummy network service level targets.