Bug 1073895 - RFE: extend timer units to allow also service deactivation
RFE: extend timer units to allow also service deactivation
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2014-03-07 07:30 EST by Karel Volný
Modified: 2016-01-27 10:06 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-27 10:06:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2014-03-07 07:30:17 EST
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 09:03:06 EST
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 09:49:02 EST
Any idea if this has already been implemented?
Comment 3 Zbigniew Jędrzejewski-Szmek 2016-01-27 10:06:47 EST
"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.