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 ([email protected]) 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
