nixos/switch-to-configuration: remove explicit tmpfiles invocation

[nikstur]

Description of changes

Remove explicit invocation of tmpfiles. Instead add a restartTrigger to the tmpfiles service unit. This makes ordering implicit and removes bespoke logic from switch-to-configuration.

This should not be pose a big issue because tmpfiles is ordered before sysinit.target, way before normal services are started.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

Priorities

Add a 👍 reaction to pull requests you find important.

[nikstur]

@ofborg test switchTest

[ajs124]

This seems like a change in semantics, which should maybe be documented.

Previously every switch executed this, whereas now, it requires a changed to tmpfiles.d.

[nikstur]

This seems like a change in semantics, which should maybe be documented.

Previously every switch executed this, whereas now, it requires a changed to tmpfiles.d.

This shouldn't be an issue. If the config (i.e. tmpfiles.d) hasn't changed I don't see what tmpfiles should've done previously.

[ElvishJerricco]

I should have looked at this earlier. This is potentially problematic. Any services with Requires=systemd-tmpfiles-setup.service and After=systemd-tmpfiles-setup.service will be stopped. A) Will they be started again when switch-to-configuration starts things? B) Will the interruption of their execution be a problem?

[ElvishJerricco]

Granted, units with those properties are probably in the "very strange" category.

Edit: Yea, to prove it, here's this on my desktop:

$ systemctl show -p RequiredBy systemd-tmpfiles-setup.service 
RequiredBy=

So my concern is probably nothing to worry about

[vcunat]

This broke nixosTests.acme and now it's blocking both nixos-unstable* channels:
https://hydra.nixos.org/eval/1802345#tabs-now-fail

[K900]

Going to revert this for now.

[ElvishJerricco]

The issue seems to be that services expect to be started after systemd-tmpfiles-setup.service is complete. Normally, they are, because systemd-tmpfiles-setup.service is before sysinit.target. But with this change, when you run switch-to-configuration, sysinit.target is already reached. So systemd-tmpfiles-setup.service is started simultaneously with services that depend on it. Therefore the tmpfiles behavior they need may not have occurred yet.

Fixing this ordering seems very non-trivial.

---

As a completely separate concern, the test had these log lines, which are concerning because they make no sense to me.

webserver # [   10.363538] systemd[1]: Stopped target Local File Systems.
webserver # [   10.364902] systemd[1]: Stopped target All Network Interfaces (deprecated).
webserver # [   10.365877] systemd[1]: Stopped target Remote File Systems.

These are things that systemd-tmpfiles-setup.service depends on. The stopping relationship of Requires= goes the other way. So I have no idea why this happened.

[nikstur]

Any services with Requires=systemd-tmpfiles-setup.service and After=systemd-tmpfiles-setup.service will be stopped. A) Will they be started again when switch-to-configuration starts things? B) Will the interruption of their execution be a problem?

This is the reason we need this though. More concretely, for the perlless activation, tmpfiles needs to run after sysusers (which it naturally is ordered after) to create files with the correct owners.

[ElvishJerricco]

@nikstur To be clear, that comment has nothing to do with why this was reverted. Totally separate concern.

Anyway, I think you have that backwards? That comment was about services ordered systemd-tmpfiles-setup -> foo, but you're describing an ordering that goes the other way sysusers -> systemd-tmpfiles-setup. So that's not what I was worried about. But again, I'm fairly confident the impact of that worry is practically zero.

[nikstur]

@ElvishJerricco you're right I got that backwards.

This comment in stc seems to describe what is happening here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/activation/switch-to-configuration.pl#L611

However, adding X-StopOnReconfiguration to sysinit.target doesn't seem to work. The test then hangs when stopping sysinit.target.

I think the easiest solution, unless maybe @dasJ shows us the way towards stc enlightenment, is to just execute systemd-sysusers in an (re-)activationScript, however cursed that may be.

[ElvishJerricco]

@nikstur Yea, you cannot stop sysinit.target. From systemd.service(5):

The following dependencies are added unless DefaultDependencies=no is set:
• Service units will have dependencies of type Requires= and After= on sysinit.target

Stopping sysinit will stop literally all services that don't have DefaultDependencies=no :P So that's not an option.

Conceptually, sysinit.target is meant to encode system initialization, not reconfiguration. So it's truly designed for things that happen once, during bootup.

I wonder if the right approach would be a new target, say nixos-reactivation.target, with a similar unit hierarchy for things we need to reconfigure, like sysusers and tmpfiles. It would mean duplicating some units from sysinit (like sysusers and tmpfiles), but if we made them RemainAfterExit=false, then stc could simply do systemctl start nixos-reactivation.target.

[ElvishJerricco]

Heck, we could even have sysinit.wants = ["nixos-reactivation.target"] to trigger any custom user activation units. This would help eliminate activation scripts. Actually the duplicated units makes this not realistic...