Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering <mzerqung@0pointer.de>]

On Fri, 22.07.11 01:08, Karel Zak (kzak@redhat.com) 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel