[Nix-dev] NixOS on systemd

[Mathijs Kwik]

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".