On Fri, 22.07.11 01:08, Karel Zak (kzak@xxxxxxxxxx) wrote: > > On Thu, Jul 21, 2011 at 06:11:25PM +0200, Lennart Poettering wrote: > > I'd expect people to just tell systemd about their preferred grouping > > (if the default of sticking each service into a group of its own is not > > good enough) using the ControlGroup= setting in unit files. This is > > trivial to do, and will put things right from the beginning with no > > complex moving around. > > It would be nice to have a shared library (or D-BUS interface) to > talk with systemd, then it would be possible to (on-the-fly) > create/modify services and execute processes by systemd from another > daemons (like crond). You can actually do that, and there are a couple of hooks provided to make this pretty: a) Your app can just place a simple unit file in /run/systemd/system, and issue Reload() on the manager D-Bus object. Then, you can start it via D-Bus, and stop it, and introspect it, and all other operations. When you want to get rid of it again, stop it, then remove the file, issue another Reload(). b) Write a "generator". This are small binaries you can drop into /lib/systemd/system-generators. They are spawned in parallel every time systemd loads its configuration. These generators can dynamically generate unit files from other configuration, and place them in a special dir in /run/systemd. We currently use this to create the appropriate units for /etc/crypttab, or to generate a getty on the kernel console if the kernel was booted with a special one. Eventually we'll probably rip the currently built-in SysV compat code in systemd out and make a generator out of it. So that we just dynamically create a systemd unit file from each SysV script. These generators must be very simple, as they are started very early at boot. They may not do IPC and they may not access any files outside of the root dir. They are primarily useful to dynamically translate foreign configuration into systemd unit files. c) In case you have a number of very similar dynamic services to run use a template. i.e. as part of your package drop yourservice@.service into /lib/systemd/system. Then, when you dynamically need an instance of this, just start "yourservice@someparam.service". In that unit file you can then access "someparam" with %i. If you need to change more than one parameter this won't be useful to you, however. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
