It only needs to be started during boot. Starting it at other times
shouldn't hurt, except that if systemd-journald is restarting at the
same time, the latter might not have a SIGUSR1 signal handler
installed yet, so it might be killed by systemd-journal-flush. (At
least that's my theory about the dead systemd-journald instances in
the build farm...)
It's only needed during early boot (in fact, it's probably not needed
at all on NixOS). Restarting it is expensive because it does a sync()
of the root file system.
systemd escaping rules translate this into a string containing '\'
which is treated by some code paths as quoted, and by others as unquoted
causing the affected units to fail.
Restarting user@ instances is bad because it causes all user services
(such as ssh-agent.service) to be restarted. Maybe one day we can have
switch-to-configuration restart user units in a fine-grained way, but
for now we should just ignore user systemd instances.
Backport: 14.04
If /boot is a btrfs subvolume, it will be on a different device than /
but not be at the root from grub's perspective. This should be fixed in
a nicer way by #2449, but that can't go into 14.04.
This reverts commit 6eaced3582. Doesn't
work very well, e.g. if you actually have the FUSE module loaded. And
in any case it's already fixed in NixOps.
Otherwise, when switching from systemd 203 to 212, you get errors like:
Failed to stop remote-fs.target: Bad message
Failed to stop systemd-udevd-control.socket: Bad message
...
These fail to mount if you don't have the appropriate kernel support,
and this confuses NixOps' ‘check’ command. We should teach NixOps not
to complain about non-essential mount points, but in the meantime it's
better to turn them off.
This seems to have combined badly with the systemd upgrade, we'll revert
for now and revisit after the 14.04 branch.
This reverts commit ad80532881, reversing
changes made to 1c5d3c7883.
This used to work with systemd-nspawn 203, because it bind-mounted
/etc/resolv.conf (so openresolv couldn't overwrite it). Now it's just
copied, so we need some special handling.
With ‘systemd.user.units’ and ‘systemd.user.services’, you can specify
units used by per-user systemd instances. For example,
systemd.user.services.foo =
{ description = "foo";
wantedBy = [ "default.target" ];
serviceConfig.ExecStart = "${pkgs.foo}/bin/foo";
};
declares a unit ‘foo.service’ that gets started automatically when the
user systemd instance starts, and is stopped when the user systemd
instance stops.
Note that there is at most one systemd instance per user: it's created
when a user logs in and there is no systemd instance for that user
yet, and it's removed when the user fully logs out (i.e. has no
sessions anymore). So if you're simultaneously logged in via X11 and a
virtual console, you get only one copy of foo.
