`switch-to-configuration` starts unmodified units

Ma27 commented 7 months ago

Describe the bug

When a unit of Type=simple gets stopped, it will be activated again by switch-to-configuration test (or ... switch) even if it didn't change.

Steps To Reproduce

Steps to reproduce the behavior:

Define a unit like
```
{ systemd.services.foo.script = '' /* ... */ ''; }
```
It's not even relevant if it's supposed to be a short thing activated by a persistent timer or a long-running script, I observed the issue with both kinds of services already. (see below for more context on its dependencies).
systemctl stop foo
switch-to-configuration test
Now, foo.service should be started again.

Expected behavior

foo.service shouldn't be started again.

Screenshots

no

Additional context

After foo.service is/was stopped, the issue can be boiled down to systemctl daemon-reload; systemctl start multi-user.target which is effectively issued by switch-to-configuration.pl.

Now, there are two combinations I've observed which may be relevant to the issue:

foo.service had wantedBy = [ "multi-user.target" ]; set. I think if the service got stopped before (e.g. by hand), it shouldn't be brought up automagically by switch-to-configuration.pl.

foo.service didn't have wantedBy = [ "multi-user.target" ]; set and no other dependencies declared. However, it had a timer foo.timer declared like this:

{
wantedBy = [ "timers.target" ];
after = [ "network-online.target" ];
timerConfig = {
  Persistent = true;
  OnCalendar = "*-*-* 00/2:00:00";
  OnActiveSec = "0s";
};
}

Notify maintainers

cc @dasj

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

Add a :+1: reaction to issues you find important.

PhilTaken commented 7 months ago

This is directly related to https://github.com/NixOS/nixpkgs/issues/228528

Ma27 commented 7 months ago

This is directly related to #228528

Oh yeah given that they also suspect systemctl daemon-reload to be part of the problem, both issues had probably the same root cause.

Originally I went from a different starting point (Type=simple most notably and in one case even w/o any timer) to investigate it and given the different base situation I also failed to find another issue being related to that :sweat_smile:

cc @winterqt I think you were right with your suspicion of systemctl daemon-reload as described above.

What I'm wondering is, is this the expected behavior of systemctl daemon-reload? I mean, it's certainly supposed to refresh its state, but not entirely sure if it's supposed to forget about units that were started up correctly. Running systemctl start multi-user.target (as opposed to systemctl restart multi-user.target) doesn't seem to start up these units. So maybe we can defer the entire issue to systemd?

NixOS / nixpkgs