Heya, as many of you probably know systemd got accepted as feature for F-14 by FESCO a few weeks back. https://fedoraproject.org/wiki/Features/systemd And in case you want to read up what systemd actually is, here's the blog post that introduced it (only slightly out-of-date, we have however advanced a bit since then): http://0pointer.de/blog/projects/systemd.html Since the acceptance by FESCO it has been added to Rawhide together with patched or updated versions of a few related packages. However, what has not been done so far is making it the default in Rawhide. So far it does not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I want to notify everybody that I am planning to do this change very soon now (tomorrow?). Then, systemd will be pulled in onto your rawhide system and is used exclusively for booting (so far, you can still choose between it and upstart in grub, with a default on upstart), and problems booting should be reported to systemd in rhbz then. At this point the following packages in rawhide have been updated to provide socket based activation [Hint: in case you are wondering, socket activation is one of the amazing things in systemd, see the original announcement for details]: dbus, udev, avahi, rtkit. Before F14 I want to at least add rpcbind and rsyslog to this list for socket based activation, and most likely cups. For rpcbind/rsyslog the patches have been submitted upstream, and even have partly been merged already). It would be great if we could ship native unit files (as replacement for the current sysvinit scripts) for as many packages in Fedora as we can for F14, and in particular for all those services that are installed by default. [Hint: unit files is the systemd term for files describing services (i.e. daemons) and other objects systemd starts and maintains]. I have prepared native unit files for the majority of services of the default install, and will now post them on bugzilla piece by piece for inclusion in the rpms. Ideally, those unit files are shipped upstream, but they can be added in the rpms too. Unit files are usually very short for normal services and should be easy to write (i.e. you don't have to think about dependencies or any complexities like that at all in most cases, unless you want to do fancy stuff involving early boot or late shut down). Unit files should be written for daemons that currently install SysV init scripts and also (and this matters!) for all services currently started via D-Bus bus activation. Writing native unit files enables the radical form of parallelization that systemd employs. Units without native unit files, i.e. only SysV or D-Bus service files, will only benefit from very minimal parallelization. Note that neither patching in socket based activation, nor shipping native unit files will break services in a non-systemd boot up. In order to keep our options open to possibly revert things before F14 we explciitly made sure not to break compatibility with non-systemd boots. i.e. the socket actviation patches become NOPs if systemd is not running and the native unit files are ignored, so that only sysv init scripts matter. Also note that even in the case that we do roll back to upstart before the release of F14 this work won't be in vain, as work that has been done has been done and will then becom euseful when we adopt systemd in the next cycle. I want to stress though that at this point in time I see no reason to assume that we shouldn't make it for F14. So, here's my call for help, in order to make this all a big success: a) if you maintain a package which includes a daemon/service from the default install, expect a proposed unit file in bugzilla soon. Would be awesome if you could check it and add it to your RPM. Even better would be if you get it merged upstream. I have unit files the majority of these services. Ping me on irc (#systemd on fdo, I'm 'mezcalero'), if you wonder whether yours is one of them, and if you have questions. b) if you maintain a package which includes a daemon/service from outside the default install, it would be awesome if you could ship native unit files too, even though I don't have any ready for you. Writing unit files is not difficult, and should be well documented in the man pages. In particular have a look daemon(7), i.e. http://0pointer.de/public/systemd-man/daemon.html and related man pages. A good example for a systemd-enabled RPM for a D-Bus service is rtkit. You might want to check it out and its .spec file: http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?view=markup A good example for a systemd-enabled RPM for a service that currently installs a SysV init script, checkout Avahi and its .spec file: http://cvs.fedoraproject.org/viewvc/devel/avahi/avahi.spec?view=markup Some package could use the native unit love more than others. For example, I have seen terrible things done to daemonize processes and drop privs in pure shell (the bittorrent packages as one example). Packages like that could really benefit from native unit files which make this much easier and nicer and cleaner. c) if you are the developer of a package that could benefit from socket activation, please consider patching it for it. How that works is documented in the man pages: http://0pointer.de/public/systemd-man/daemon.html and http://0pointer.de/public/systemd-man/sd-daemon.html and related, see http://0pointer.de/public/systemd-man/ for the full list. d) There's one thing that is not directly related to systemd but which I'd really like to see done at the same time: moving /var/lock and /var/run to tmpfs, like suse and ubuntu already did it. The changes necessary should be small, but probably in a non-trivial number of packages: each mention of /var/run in the .spec files needs to be %ghosted. Also, some minimal changes to rc.sysinit need to be done, so that the dirs are mounted (this could be done by systemd too, in case we get the sysinit split hhoyer started to work on done before F14). Finally, there might be a few packages which start to act confused if their directories beneath /var/run is go away on reboot. But these problems should already have been fixed by the Ubuntuans and Suses of this world for us. It would be really great if somebody would volunteer for this and go through the packages to add %ghost everywhere and ensure otherwise this works out. The ubuntu and suse folks might have some docs around with more ideas about this. e) play around with systemd, test it! f) contribute to our work! We always are happy about people contributing code or docs, or even artwork (we could use a logo... ;-)). And again, if anybody has a question, many systemd folks are around on #systemd on fdo, and particularly me, mezcalero. So if you have questions, ask us there, or right here on this thread. There are a couple of bugs that still need to be fixed in other packages than systemd, before F14: https://bugzilla.redhat.com/show_bug.cgi?id=614245 https://bugzilla.redhat.com/show_bug.cgi?id=612789 https://bugzilla.redhat.com/show_bug.cgi?id=612728 https://bugzilla.redhat.com/show_bug.cgi?id=612712 That said, things should already work really well in rawhide right now, and you should have no trouble bringing up and down the system with systemd using its sysv compatibility logic to execute the existing SysV init scripts. Please try it out and report back. Note that you still need to pass "init=/bin/systemd" on the kernel command line, until the point I make the change i mentioned above. A short FAQ: 1) Q: If I patch my service for systemd socket activation, will this break things for people not using systemd? A: No, it won't. 2) Q: If I ship native systemd unit files, will this break things for people not using systemd? A: No, it won't. 3) Q: Will things become miraculously fast by booting with systemd? A: No, it won't. When you boot with only SysV services (i.e. utilizing the systemd SysV compatiblity logic to its max), things should become only very little faster, as only very minimal parallelization is employed then. And even if you have added native service files for every single service, you won't make a slow machine a supercomputer. Speeding up the boot requires a lot of work everyhwere, and it is not sufficient to parallelize only daemon bootup. i.e. rc.sysinit needs more parallelization too, and is currently a single linear monolithic script. That said, on SSD things should be noticably faster (though don't expect too much), on rotating media things are not as rosy, simply because the Linux IO scheduler cannot fully keep up with with the increased parallelization and readahead is not a solution for this, but more of a kinda futile attempt to fix this without touching the kernel. Stuff like Jens Axboe's fcache sound like a better solution, and even a bit like the approaches MS and Apple took in this area. Let me stress here however that I would like to see people judge systemd not by its mere speed. Please see the full set of features (again, read the initial blog post for details and maybe even the man pages). It is our main objective to do things right. One part of "doing it right" is "doing it fast", but it's far from the only thing. 4) Q: If I don't care about systemd and don't update my packages, will things stop working for me in F14? A: No, they will continue to work. Since systemd's SysV compatiblity is quite extensive things should just continue to work just fine. 5) Q: Why systemd? Isn't Upstart awesome too? A: Well, opinions on that matter, see my original blog story for details. Suffice to say that I am not exactly the only one who thinks this way. 6) Q: LSB/SysV init scripts are standardized in the LSB! Why are you breaking with that standard? A: Well, actually we aren't. systemd provides compatibility with SysV to a very large degree, we even have support for various distribution extensions. The vast majority of init scripts should continue to work in systemd just fine, even though they might work even better with native unit files. In the long run we actually hope to minimize differences between distros with this, by establishing common hooks services should use and asking everybody to use those hooks and ship their service files in their upstream packages. The idea is that the systemd unit file is automatically a lot more portable and distribution-independent then the init scripts ever were. 7) Q: Are the other distros switching too? A: Well, they are not as fast, but it looks very much like it. I have been working very closely with Kay Sievers from Suse to integrate systemd equally well into the OpenSuse semantics, and it will enter their distro as soon as their development cycle reopens. Debian, Gentoo, ArchLinux have packages in their archives, but it's not the default there (yet?). I guess at least for Debian/Gentoo it is very hard to make decisions about dfaults like this. Meego has someone working on this, but I have not followed that closely. And there are some smaller distros which have adopted it too, and I know at least one (Pardus) that plans to make it the default in the next release. And regarding Ubuntu I leave it to you figuring out what is going on (Hint: you might want to check out for what company the main developer of Upstart -- which systemd replaces -- works for...). And never forget that Fedora is of course the leader in development, so it should be us who lead here... ;-) And if you have any further questions, talk to us on IRC! Or reply to this thread! And also, don't forget to check the (extensive I believe) body of documentation we now have, it might already answer your question. In particular the blog story I already mentioned way too often: http://0pointer.de/blog/projects/systemd.html It's quite a novel I fear, but full of interesting stuff. And then there is the set of man pages: http://0pointer.de/public/systemd-man/ Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
