On 06/10/2015 03:02 PM, Stephen Gallagher wrote:
You make some good points Jóhann. It probably does make sense to focus (at least at first) on managing timer units shipped alongside services as opposed to trying to develop a UI for managing arbitrary timer units. I'll discuss this with some of my colleagues. That said, there still may be some value in enabling the creation of new timer units for these purposes. (For example, there may be timers that are only useful if two normally-unrelated services are installed, so neither one would be likely to ship such a timer in their package, even disabled). But it's hard to say whether that's worth designing for or solving by shipping additional packages with helper units.
Now that I see that you have started to understand what I tried to convey when running that cron to timer migration but failed miserably in doings so, going to say that value is an illusion Ithrow in another ( real life ) example to complex matters further.
Let's use this drupal related cron job as an example "|0 * * * * wget -O - -q -t 1 http://www.example.com/cron.php";| that many will be familiar with which you would migrate to native systemd timers.
Shipping this with drupal cannot be done since you cannot bind that to a specific web server ( the installed server might be apache, might be lighthttp or might be nginx etc ) not binding it to the web server will keep this timer unit running with all it downside once the administrator shuts down the webserver ( as happens currently with cron ).
What I'm trying to emphasize here there exist only one to one mapping with each service ( or target ) and timer unit and those two things need to be bound together.
With my former cron to timer feature and serverWG hat on, what I would propose and do which is quite the opposite from what you propose here is have all components ship their cron job in a separated sub-package ( those are mostly crap anyway ) then design the cockpit UI in such manner that dissociates cron job and uses generic term like for example "scheduled task" which covers both solution and whatever the future might bring and offers the user to create an arbitrary task ( which would use cron and have screen(s) tailored to that and create and associate task to an service ( with screen(s) tailored to that which would use timers )
JBG
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
