It's not entirely clear why this happens, but sometimes /proc/1/exe
returns a bogus value, like
/ar3a3j6b9livhy5fcfv69izslhgk4gcz-systemd-217/lib/systemd/systemd. In
any case, we can just conservatively assume that we need to restart
systemd when this happens.
Fixes#10261.
Clearly it would be the best if we'd directly generate mount units
instead of converting /etc/fstab. But in order to do that we need to
test it throughly so this approach is for the next stable release.
This fix however is intended for inclusion into release-14.12 and
release-15.09.
Using a simple regular expression unfortunately isn't sufficient for
proper mount unit name quoting/escaping and there is a utility in
systemd called systemd-escape which does nothing less than that.
Of course, using an external program to escape the unit name is way more
expensive and causes us to fork for each mount point.
But given that we already do quite a lot of forks just for unit starting
and stopping, I think it doesn't matter that much. Well, except if you
have a whole bunch of mount points.
However, if the latter is the case and you have thousands of mount
points, you probably have stumbled over this already if your mount point
contains a dash.
As for my motivation to fix this: I've stumbled on this while trying to
fix the "none" backend test for NixOps (see NixOS/nixops#350), where the
target machines use /nix/.ro-store and /nix/.rw-store as mount points.
The implementation we had so far did improperly escape it so those mount
points got the following unit files:
* nix-.ro-store.mount
* nix-.rw-store.mount
The correct names for these units are however:
* nix-.ro\x2dstore.mount
* nix-.rw\x2dstore.mount
So using systemd-escape now properly generates these names.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Many bus clients get hopelessly confused when dbus-daemon is
restarted. So let's not do that.
Of course, this is not ideal either, because we end up stuck with a
possibly outdated dbus-daemon. But that issue will become irrelevant
in the glorious kdbus-based future.
Hopefully this also gets rid of systemd getting stuck after
dbus-daemon is restarted:
Apr 01 15:37:50 mandark systemd[1]: Failed to register match for Disconnected message: Connection timed out
Apr 01 15:37:50 mandark systemd[1]: Looping too fast. Throttling execution a little.
Apr 01 15:37:51 mandark systemd[1]: Looping too fast. Throttling execution a little.
...
Since we restart all active target units (of which there are many),
it's hard to see the units that actually matter. So don't print that
we're starting target units that are already active.
‘nixos-rebuild dry-activate’ builds the new configuration and then
prints what systemd services would be stopped, restarted etc. if the
configuration were actually activated. This could be extended later to
show other activation actions (like uids being deleted).
To prevent confusion, ‘nixos-rebuild dry-run’ has been renamed to
‘nixos-rebuild dry-build’.
Now that dbus reload has been moved before restarting units,
the reload may fail if dbus has been stopped before.
The reload-or-restart will reload dbus if it's active,
otherwise start it.
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
...
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.
If you define a unit, and either systemd or a package in
systemd.packages already provides that unit, then we now generate a
file /etc/systemd/system/<unit>.d/overrides.conf. This makes it
possible to use upstream units, while allowing them to be customised
from the NixOS configuration. For instance, the module nix-daemon.nix
now uses the units provided by the Nix package. And all unit
definitions that duplicated upstream systemd units are finally gone.
This makes the baseUnit option unnecessary, so I've removed it.
switch-to-configuration.pl is currently hard-coded to assume that if a
unit is in the "auto-restart" state that something has gone wrong, but
this is not strictly true. For example, I run offlineimap as a oneshot
service restarting itself every minute (on success). NixOS currently
thinks that offlineimap has failed to start as it enters the
auto-restart state, because it doesn't consider why the unit failed.
This commit changes switch-to-configuration.pl to inspect the full
status of a unit in auto-restart state, and now only considers it failed
if the ExecMainStatus is non-zero.
Currently switch-to-configuration.pl uses system() calls to interact
with DBus. This can be error prone, especially when we are parsing
output that could change. In this commit, almost all calls to the
systemctl binary have been replaced with equivalent operations via DBus.
