On 06/09/2015 10:21 PM, Lennart Poettering wrote:
On Tue, 09.06.15 19:33, Jakub Skořepa (ja...@skorepa.info) wrote:
Hello,
My name is Jakub Skořepa and I'm working on Cockpit UI for Systemd
Timers.
For that I need to create and modify systemd unit files. Cockpit uses D
-Bus for everything so I need D-Bus API for that. I think that it would
be beneficial if systemd was able to create unit files on-the-fly using
through D-Bus method call.
You can do that already, in the concept of "transient" units. However,
these units are not persistent, they are stored in /run and go away on
reboots. Google for the StartTransientUnit() bus call for details.
I think it would be a good idea to also allow to create persisent
units in a similar way eventually. However, that's not as obvious and
easy as it sounds, it starts from the question where to store those
units. Cron-like semantics would suggest somewhere below /var, but
that means they aren't available at early boot, and we'd have to
reload the configuration and requeue all jobs when /var appears. Which
means we'd have to put them in /etc instead, which however is
suboptimal for many usecases....
I think I'd be willing to merge a patch that adds adds a new bus call
CreatePersistentUnit() that works like StartTransientUnit() except
that it only creates but not starts a unit, and that it stores the
unit in /etc. (Note: the only reason StartTransientUnit() not only
creates but also starts a unit is because the unit would otherwise be
GC'ed away immediately and not be reconstructable after that...)
I hate to say this since I'm against litter unit files across the entire
filesystem like infective disease and administrator then have to run
around trying to chase them down but is it not better to store this
under /srv somewhere [1], not etc, so it wont conflicts with "Stateless
Systems, Factory Reset, Golden Master" Systems?
On top of that if this gets created under /etc it's a free for all for
administers to tinker with.
Arguably supporting this et all or supporting this without forcefully
having to bind those timer units with an existing type service unit is a
mistake so it might just be better to direct them to install and use
cron instead and have cockpit drop a snippet into /etc/cron.d and the
likes instead
Jakub,Stephen what's the end game with this as in what kind of timer
definitions do you expect administrator be doing and support from the
cockpit UI?
1. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
