[systemd-devel] Creating units using D-Bus

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

On 06/09/2015 10:21 PM, Lennart Poettering wrote:
> On Tue, 09.06.15 19:33, Jakub Skořepa (jakub at 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