Otherwise, the enabled -> disabled transition won't be handled
correctly (switch-to-configuration currently assumes that if a unit is
running and exists, it should be restarted).
/tmp cleaning is done by systemd rather than stage-2-init
enableEmergencyMode moved from systemd to seperate module
new option to mount tmp on tmpfs
new option to enable additional units shipped with systemd
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
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.
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.
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.
