Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
]] Stefano Zacchiroli
| I've just read a few days ago the design document of systemd; AFAIU it
| requires anyhow patching various daemons, no matter how trivial the
| patches are.
No, it doesn't require it, but it allows it. Cutting and pasting from
Lennart's blog post:
An ideal daemon for use with systemd does a few things differently
then things were traditionally done. Later on, we will publish a
longer guide explaining and suggesting how to write a daemon for use
with this systemd. Basically, things get simpler for daemon
developers:
[List of possible, but not necessary simplifications]
Note that systemd supports daemons not written in this style perfectly
as well, already for compatibility reasons (launchd has only limited
support for that). As mentioned, this even extends to existing inetd
capable daemons which can be used unmodified for socket activation by
systemd.
So what systemd gives you is the ability to chuck away a fair amount of
the boilerplate code in your daemon. It doesn't require it. If a
daemon double-forks and calls setsid (to get away from the tty where
it's started from), it'll still be captured and controlled by systemd
because of cgroups.
| Do you have any experience or feeling on how usable it would be today in
| a Debian unstable box? Can we imagine having it as an alternative init
| which a Squeeze user might want to try, obtaining something more than a
| machine that simply doesn't boot half of the machine services?
I am so far just testing on a singe machine, but it's my firm belief
that it's possible to have a fully functional systemd in squeeze.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: