Yeah, I did not write for a while, but that does not mean I'm dead or changed interests, just that running an always growing company is taking lots of time, with the spare time I get being invested in something interesting and relevant, usually that does not translate to blog posts :-P However I felt like doing it today.
While most people know me due my graphical user interfaces work, likely related to Enlightenment, I'm one of those guys that like to consider the system as a whole and not just a subset of it. My main interest since 1998 is graphics, from good old days of tcl/tk and gtk1 to pygame/sdl to qt3/4 and later enlightenment. But I always kept an eye on other bits like boot, networking, sound and so on.
After getting into
ConnMan to have a good (and fast) network infrastructure, I started to consider similar bloat-reducing options to other parts of the system. Talking to friends like Holtmann, Lennart and ProFUSION co-workers about the stupid stuff we do in our distributions, like abusing shell scripts for no good... even tried to resurrect Gentoo's bug
#69579 (Bootup Time Reduction/General Speedup).
My first idea was simple, hackish and selfish: as I'm Gentoo user, I could write a shell script compiler that generates threaded-C code with the exact state machine I'd have using /etc/init.d with OpenRC. It was
simple (or not so complex) as most of the scripts are start-stop-daemon wrappers with dead-simple usage of OpenRC's dependency information (need, use, after, before...). However it was
hackish because couple of them are not simple and would require hacks, either special cases or rewrite them natively, to make it work. Last but not least, it was
selfish as likely it would just fix my problem, or with some luck it could benefit Gentoo as a whole. All of that after I loosing faith in Upstart of couple of tries and talks with related developers.
However sometimes it is better to talk to smart(er?) people before you go do your own stuff. I don't feel like I suffer from NIH-syndrome. So talking here and there, João Paulo pointed that Lennart had a still secret project to do exactly what I was aiming, but knowing Lenny, it ought to be good. So I immediately
/q -freenode mezcalero and started chatting, with he demonstrating a great cleverness and even proving me wrong in some assumptions, he already thought of much more like merging inted features and how to isolate services in their own control groups... yeah, he got me in systemd's bandwagon.
As I still have tons of other stuff to do, I put the idea on hold and went back to it after several posts and announcements that Fedora 14 would use it. At the first free time slot I checked out the code and Gentoo's "port". Well, as expected with young projects it did not cover some special cases, like systems without IPv6 (mine) and Gentoo's /etc/init.d scripts were too smart due OpenRC's dependency resolver that would make their usage more harm than good. So I had work to do, but it was done and contributed back, with awesome results.
The project and community, also composed of other nice and helpful hackers such as Kay Sievers and Michael Biebl and I felt like it was an excellent project ProFUSION could collaborate, then we invested 2 developers to help it: Fabiano Fidencio and Lucas de Marchi, that got it running on Arch (OpenEmbedded on the way) and added some missing features, like native poweroff/halt/reboot, compile time toggle to disable SysV backward compatibility and so on, runtime fallbacks if no IPv6 and so on.
Right now systemd is very powerful, it can almost fulfill all my needs and likely can manage everything an embedded system would use on its own. From its lightness that reduced my boot in 10s and 2000 process, to nice helpers like its syslog-kmsg bridge. In my opinion, the biggest missing feature is cron-like features to reduce yet-another daemon from boot and centralize it in the "system daemon -- systemd".
If you don't know it yet, give it a try. It's young however very mature, handling complex cases, providing nice utilities and trying to unify Linux boot process. A short list of its awesomeness would be:
- each service is isolated in its own control group, being able to apply limits and avoid children processes to exit their parent's control (ie: php/perl from cgi-bin exit from their apache tree). Aside from safety, this allows monitoring when a forking service died as all process in its cgroup are gone.
- socket activation, like inted/xinetd, allows seldom used servers to not add load to boot process yet they still work as expected, like sshd and cupsd for desktop systems.
- lazy mount of filesystems by means of kernel automount. Similarly to socket activation, this lazy mount avoids adding load to boot process and postpone the actual mount when the system actually need files from such mountpoint.
- easy to read/write configuration files (units) with ini-like syntax, matching other freedesktop.org projects such as dbus.
- native support, properly written in C, to various boot tasks such as loading modules, load/save random seed, clean temporary files, setup console fonts and keys, enforcing quota checks, creating required directories with correct permissions and so on.
- useful helpers such as systemd-kmsg-syslogd that directs /dev/log to /dev/kmsg, that avoids the need of a proper system logger with logrotate on embedded (or desktops that doesn't need persistent logging).
- awesome readahead code that uses fanotify (temporarily disabled in 2.6.36) to passively collect read files, even while replaying already collected from previous boot -- without stepping on its own toe or major performance hit.
- proper integration with DBus to provide race-free activation of system services.
- various agent interfaces to request user intervention, like passwords.
- proper remote control interface (uses DBus)
- proper (optional) SELinux and auditd labeling and interaction.
All in all I really like Systemd and I foresee a brilliant future for it, given major distros adopt it officially (Fedora and OpenSuse at least?)