systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Wed, 26.05.10 15:42, James Findley (sixy at gmx.com) wrote:

> > It is completely clear that there needs to be some flexibility in any
> > init system to cater to real-world services.
> >
> > But it is also clear that there is a difference between gobs of shell
> > script and nice and clean files like the ones you find in /etc/init.
> 
> 
> Actually the blog post is proposing exactly that, as I read it.  And it 
> seems not only that lots of other people read it the same way, but some 
> even agree with it.

No, this is not what is meant.

So, the plan is (and much of this is actually implemented already) is to
go through /etc/init.d and similar directories, and look at every script
individually. Then, figure out the common parts, and see if we can
perhaps implement that elsewhere and in C at some other place.

Example: /etc/rc.sysinit mounts a lot of API filesystems (such as /proc,
/sys, /dev). We can do that already in the init system, very early
during boot, in C. If we do this (and we did) the code is much shorter,
and nicer, and does not require forking or anything.

Another example: /etc/init.d/autofs loads the autofs4 module and sets up
permissions on /dev/autofs. Wouldn't it be nicer if this would be done
outside of a shell script? And so we decided to do that and moved this
into udev and module-init-tools: instead of loading the module manually
and setting up the device nodes manually we just create the device nodes
in advance and apply permissions to it via udev rules (like any other
device node) and then autoload the autofs module on first access. (and
this has already hit rawhide by now iirc)

Another example: /etc/init.d/btseed and .../bttrack include some
amazingly evil code to fake daemonization of a process with & and
disown, as well as privilege dropping in shell. We can cover that much
nicer in systemd, and provide the right and clean daemonization it needs
out of the box. And so we added just that to systemd itself. (i.e. there
is a User= and option in the .service files and a Type= option that
allows you to tell systemd to do the necessary daemonization properly.)

And a fourth example: if you look at /etc/init.d/cups you'll find some
code in there that tries to make sure that sun RPC doesn't take away the
CUPS port numbers. (It also retriggers the printers in the udev sysfs
tree, which seems to be very wrong, i really wonder what that is
for. Anybody please enlighten me?) But the port number issue can easily
be fixed by systemd allocating the port number right-away, and this we
can easily cover in plain C in systemd itself via .socket units. And
that's what we did.

So, in summary: we go through the shell scripts and figure out
piece-by-pice whether we can find a better, perhaps more generic place for
it. And the right place could vary: it could be systemd itself (maybe a
new option in .service is sufficient, like the Type= or User= option
mentioned above) or udev or module-init-tools, or
in the daemon code itself. 

And suddenly, after you did this you notice that in those shell scripts
the only thing that remains is boilerplate code, more often than not
just the simple code copied 1:1 from the fedora reference init
script. And the boilerplate code is redundant if you use native .service
files.

So, there are no plans at all to replace the shell scripts 1:1 with
their equivalents written in C. There will not be a shell-to-C compiler
or anything like that. What we want to do (and already did for quite a
few daemons now), is to replace many of the shell hacks by C code at
better, more generic places of basic OS.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4