[systemd-devel] Creating units using D-Bus

[Stephen Gallagher]

On Wed, 2015-06-10 at 13:21 +0000, 
> 
> 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.
> 

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150610/3b4cad48/attachment-0001.sig>