Bug 82180 - RFE: Allow multiple Unit= entries in timer units
Summary: RFE: Allow multiple Unit= entries in timer units
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium enhancement
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-05 07:09 UTC by freedesk.apriori
Modified: 2014-08-18 20:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description freedesk.apriori 2014-08-05 07:09:16 UTC
It would be convenient if timer units could, in analogy to multiple ExecStart entries in services, specify multiple Unit= values, which are then run sequentially (or perhaps in parallel, when specified by some syntax) when the timer triggers.

While one could achieve this by having a single Unit= in the timer and multiple ExecStart= in the associated service, it might not always be prudent or desirable to implement this at the level of .service files. E. g., when the services combined in one timer are usually used in isolation; combining them would then require duplication parts of those service units, whereas a single timer with multiple Unit= entries would be cleaner.

This would also be one way of addressing the problem that timers currently cannot be orchestrated to run sequentially (cf. https://bugs.freedesktop.org/show_bug.cgi?id=82084).
Comment 1 Lennart Poettering 2014-08-13 23:48:00 UTC
This is actually much harder than it sounds, since if you have multiple units to watch you actually need to figure out when to reenable the timer again, after you started them. 

Currently, as there's only one unit per timer that we activate everything's simple and clear, we just track the runtime of that unit and reenable the timer after it is done. But if you have multiple this gets more complex...


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.