On Wed, 26.05.10 15:42, James Findley (sixy@xxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
