]] 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk61t7vn....@qurzaw.linpro.no
