[systemd-devel] Creating units using D-Bus

["Jóhann B. Guðmundsson"]

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