Bug 1073895 - RFE: extend timer units to allow also service deactivation
Summary: RFE: extend timer units to allow also service deactivation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: systemd-RFE
TreeView+ depends on / blocked
 
Reported: 2014-03-07 12:30 UTC by Karel Volný
Modified: 2016-01-27 15:06 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-01-27 15:06:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Karel Volný 2014-03-07 12:30:17 UTC
Description of problem:
Trying to schedule some calculations to night time when the machine is unused, I've found that I'm unable to create a clean, non-hackish solution based on timer units.
The current implementation allows to activate a service based on timer event, but it doesn't provide a mechanism to deactivate it.
This is fine for oneshot things like backups, when the job finishes itself, but doesn't work out when the job can run ad infinitum.

There should be possibility to deactivate units the same way they can be activated via timers, i.e. allowing also various combinations like 

activate
OnCalendar=*-*-* 22:00:00
deactivate
OnUnitActiveSec=28800

In addition, it'd be nice to have a possibility to optionally keep track of times when the unit should have been active and try to activate the unit later if it wasn't possible at the exact time (something like anacron(*)) - reusing the abovementioned example, if the system was powered off and then powered on and booted at 23:00 then the service would get activated right after the boot and would run until 7:00 the next day, but if the rules were:

activate
OnCalendar=*-*-* 22:00:00
deactivate
OnCalendar=*-*-* 06:00:00

then it wouldn't run 8 hours but just 7 hours from the boot at 23:00 to the defined 06:00 the next day.

Also, a question raises how to handle reboots - if the machine would run, then on 22:00 the service would be activated, then at 23:00 the machine got rebooted ... I see three options:

1) if not set to keep track of the time, the service would not be reactivated after reboot, finito, no further action

2) if set to keep track of times, the service would get reactivated after rebooot and:

a) by default the OnUnitActiveSec would count the total run time i.e. before and after reboot

b) another option would be to have a possibility to specify that the service must run the set number of seconds uninterrupted, i.e. the OnUnitActiveSec counter would be reset

... well, in fact, better implementation than creating an option to change OnUnitActiveSec behaviour would be to introduce different counter like "OnUnitSubsequentActiveSec" so that the admin could choose which one to use.


Another example, aside from overnight computations, could be e.g. networking, some providers offer better speeds/prices during off-peak hours, and so on ...


(*) While at it, I'm missing this "run later if the system was off at the given time" functionality completely, am I overlooking something?

Comment 1 Zbigniew Jędrzejewski-Szmek 2014-03-07 14:03:06 UTC
anacron functionality is planned, but so far nobody has started working on it.

I'm not sure if we want to add service stopping functionality to timers. It should be enough to schedule 'systemctl stop service.service' or 'systemctl stop service@*.service' and add a timer to call it whenever.

Comment 2 Jan Synacek 2016-01-27 14:49:02 UTC
Any idea if this has already been implemented?

Comment 3 Zbigniew Jędrzejewski-Szmek 2016-01-27 15:06:47 UTC
"anacron" is implemented as Persistent=yes/no:
http://www.freedesktop.org/software/systemd/man/systemd.timer.html#Persistent=

Service deactivation wasn't implemented, but like I said in comment #1, I don't think it's necessary.


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