On 06/10/2015 12:30 PM, Stephen Gallagher wrote:
A good overview of what we're aiming to accomplish can be found here: h ttps://github.com/cockpit-project/cockpit/wiki/Feature:-Systemd -timers#stories Though at the end of the day, it might be fair to say that systemd timers are cool and very capable and we really just want to have a decent UI for people to manipulate them. Cockpit seems like a good place since it already does management of a lot of other systemd functionality for Fedora Server. If you have specific questions or concerns with that design, we'd love to hear them.
Timers are not suited to all administrated tasks ( only the ones that relate to bootup,hardware and daemons ) and you seem to have fallen into the trap of taking the cron concept and start applying it to timers ( as opposed to simply continue to use cron ) when it's not the same thing, ( to me it is the same as you take the run level concept and apply it to systemd boot targets and think that it's the same thing) and what's describe there on that story page is something that cron is better suited to handle ( and probably much easier to implement as well ).
Now as I mentioned before you need to bind every timer unit that get's created with the relevant service running on the host. so when a daemon is started or stopped or even uninstalled ( think for example postgresql + postgresql backup timer service ) , or device appears then disappears the relevant timer unit is stopped in the process however timer units are not suitable for end user tasks ( which are the only thing that is listed there on that story page ).
As I mentioned on numerous occasion when I was driving the cron to timer migration effort in Fedora that timers and cron are solution that complement each other not replace each other, which why the cron jobs to be migrated to native times units was limited to roughly half of the total of shipped cron jobs in the distribution.
I guess the best way for you to realize this is to set up a batch server with 20, 50 or hundreds of timer units and maintain it and you will quickly understand timers shortcomings and why they should not be used for end users usecase like the ones on that story page.
You most certainly can make administrators life more hell by using timers for all usecases, just like you can drive on the wrong side of the road but you shouldn't.
JBG _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
