[systemd-devel] Creating units using D-Bus

[Stephen Gallagher]

On Wed, 2015-06-10 at 10:46 +0000, 
> 
> 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?



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.
-------------- 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/2fdc60bf/attachment.sig>