Eelco, I extended your systemd branch a bit, please have a look (and merge if you like) here: https://github.com/bluescreen303/nixos/commits/systemd
The main change I think we need to make, is to change most preStart scripts for services into systemActivation scripts. Most of these scripts are just initial setup commands, like making directories, ensuring ownership and such. This only needs to happen once, not on every service invocation. If we want to gain the extremely fast boot-times systemd offers, getting rid of all bash scripts is really gonna be the biggest factor. To facilitate this, I added most systemd unit options that can handle binary invocations without the inbetween bash glue. @Marc Weber You asked about a list of advantages for switching to systemd. Although I'm not very experienced in its use yet, I've experimented with it a bit about a year ago on Arch and loved it so much that it the main reason for delaying a switch to Nixos. Of course I soon noticed nixos was far superior, so I switched anyway, but have been wanting systemd back ever since. I will try to explain why I like it so much: In its core, systemd acts like a state machine for the entire system. The main focus is on parallelization and care has been taken everything is event-driven (no polling). It tightly integrates with modern systems such as udev and dbus and is able to fully manage the entire system (more on this later). Basically it is capable of calculating the best transaction from state A to state B. As NixOS is perfect for describing these (static) states, this is a very nice match. Every bit of information about state is confined into declarative "unit" files. A unit can be far more than just a service description, but it can describe hardware, mount points, sockets, inotify-watched files/dirs and more. Most units for hardware and mount points are created on-the-fly. Units can be grouped into "targets", which are far more modular than runlevels, as they are not exclusive. So you can think of all kinds of high level targets, like "on-battery", "on-ac", "development-services" or "at-company-network". These units are connected through a very powerful, declarative mechanism that does not just allow you to specify dependencies, but ordering, conflicts, weak- and 2-way-deps as well. Combine this with the special units (socket, watch dir), and you have an inetd replacement and path-based activation. Systemd also "stubs" sockets and mount points, so services can startup already while the real "provider" of a socket or mount point is also still starting. As an example of this, a mysql stub socket can be created, so apache/php can safely startup without the risk that the db is not fully initialized yet. Systemd will just handle the socket (buffer/wait requests) until mysql takes over. This is very powerful, as it allows you to just specify what you need, instead of manually polling/waiting/slowing down startup. Systemd tightly controls the entire system. Far more so than upstart. It feels a bit like comparing NixOS to other distributions. NixOS fully knows everything is in a consistent state on disk, knows all dependencies, and makes sure no cruft exists from previous/other configs. Systemd is similar, because it tracks everything services do, no matter how many times they fork or sub-processes they spawn. If other services need to stop/restart because of this, it knows when/how to do this. To do this, it makes heavy use of linux cgroups. This gives very powerful insight into why a certain process is running, and what unit it belongs to. Cgroups also provide a special kind of isolation, so it's possible to create chroot-jails, or run a systemd system within another systemd system (lxc container). Nice examples of this are given in the blog post series I mention below. Work has also started to make systemd manage user sessions (gnome/kde/xfce session), if you've ever looked at the startup files for those environments, it's easy to see how complex they have become (plugging in to dbus, run ssh/gpg agent, run indexing daemons). As systemd has advanced resource-limiting and watchdog-like monitoring capabilities as well, you can easily see how it can also be used as a replacement for services like monit. Last but not least: systemd aims to replace a lot of legacy standards that have existed since the early days of unix, from the time where systems were a lot less dynamic. Effort has been made to unify distributions and their configurations. This has been done with a lot of communication with distro maintainers, to make sure the generic solution is the best of all worlds. Most bootup scripts and config stuff that all distributions have (in some form or another) have been replaced by small, modern c utitilies, leading to enormous speedups. With these utilities, systemd is fully capable of bringing up/down/suspend/hibernate a modern system with things like LVM, LUKS, NFS and things like that. Unifying this between distributions is something that I think was desperately needed, and it seems this was done in a way that distros can live with, and doesn't rule out special handling some might want. Although this sounds like a lot of changes, everything was done in a way such that implementing systemd can be done step by step, without forcing you to do an enormous overhaul. I hope I have cleared up a bit on what I think systemd can give us. For NixOS, I think the main things needed are: - replacing current jobs with systemd services. - activate the cool new features like sockets for these services - get rid of more shell scripts that run during boot or service initialization. - think of common targets like "networked" "on battery" and other things modules can plug into those and users can choose which targets to activate when, instead of having just 1 all-inclusive environment. That's all for today :) To learn a bit more, look at the manual pages - systemd.unit - systemd.service - systemd.exec - systemd.special Other nice material to skim through: http://www.freedesktop.org/wiki/Software/systemd below "The systemd for Administrators Blog Series". _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
