Bug 879370 - [RFE] Timers condition to require a minimal network service level
Summary: [RFE] Timers condition to require a minimal network service level
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-22 17:16 UTC by Ales Kozumplik
Modified: 2014-09-30 23:40 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-14 18:03:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ales Kozumplik 2012-11-22 17:16:18 UTC
Description of problem:

There are services that should only run when the machine has access to a certain network service, for instance the user doesn't want to run his automatic backup scripts or synchronize the package metadata (bug 878826 comment 2) when he's connected via a roaming 3G. The timer could get a new option to specify the minimal network service level, e.g:

[Timer]
OnBootSec=10min
OnUnitInactiveSec=1h
Unit=my-expensive-backup.service
NetworkServiceAtLeast=Ethernet

This timer in this example would only run then when the machine has a wired connection to the network.

Comment 1 Bill Nottingham 2012-11-26 20:35:04 UTC
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'.

Comment 2 Ales Kozumplik 2012-11-27 11:06:21 UTC
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.

Comment 3 Lennart Poettering 2013-01-14 18:03:49 UTC
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.

Comment 4 Ales Kozumplik 2013-01-15 13:02:07 UTC
(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.

Comment 5 Michal Schmidt 2013-01-15 13:24:27 UTC
(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>

Comment 6 Michal Schmidt 2013-01-15 13:36:40 UTC
(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.

Comment 7 Ales Kozumplik 2013-01-15 14:03:16 UTC
(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?

Comment 8 Michal Schmidt 2013-01-15 14:26:27 UTC
(In reply to comment #7)
> Is that really a problem?

No.

Comment 9 Lennart Poettering 2013-01-15 22:18:35 UTC
(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

Comment 10 Ales Kozumplik 2013-01-17 14:55:22 UTC
Opened NetworkManager bug 896572 for the dummy network service level targets.


Note You need to log in before you can comment on or make changes to this bug.