loginctl user lingering configuration revisited

[tomeon]

Description of changes

Follow-up to #260248 (and related to #3702). The main goal is to address the concerns expressed in this review comment; namely, that user lingering settings should be left alone when users.mutableUsers is enabled.

Questions for reviewers:

1. Error handling in update-users-groups.pl. This script warns, but does not abort, if something goes wrong with enabling or disabling lingering (e.g. failure to create or remove files under /var/lib/systemd/linger) (at least, this is true when using the fallback implementations of do{En,Dis}ableLinger). Should these warnings be promoted to fatal exceptions?
2. Does it make sense to have fallback implementation of do{En,Dis}ableLinger? IIUC /run/booted-system/sw/bin/loginctl is not guaranteed to exist when the relevant activation script runs.
3. Is /run/booted-system/sw/bin/loginctl the correct choice of loginctl path? Should update-users-groups.pl instead use (for instance) ${pkgs.systemd}/bin/loginctl?

Note that I incorporated the user lingering management implementation into update-users-groups.pl because this makes it easy to detect whether a given user account is newly-created or not, and thereby determine whether it is okay to touch the user's lingering setting when users.mutableUsers is enabled.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/) (kinda sorta non-applicable, though I did test the functionality of the executable [update-users-groups.pl])
• 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.

[ToxicFrog]

Thank you for this comprehensive and welcome improvement to lingering support! The diff looks good; I can try patching this in and testing it locally, if you like, although I don't have any mutableUsers systems.

Thoughts on the questions:

(1) In general, my experience with nixos activation scripts is that most things are warnings, and in particular failing to successfully start/shutdown services are warnings and the activation script still runs to completion. Since this will have similar effects on failure (some services that should stop will keep running, or services that should start won't) I'd expect it to have the same severity level.

(2,3) My preference is always to use the version from the nix store rather than trust the one in /run/current-system to exist; for activation scripts in particular I'm not actually sure where in the process /run/current-system gets populated, so I don't know whether this code as written would use the loginctl from the previous generation or the one being activated.

[tomeon]

@ToxicFrog -- thank you for the feedback!

Re (1) sounds good; thanks for the shot of confidence.
Re (2)/(3), I've updated the update-users-groups.pl script to use an approach similar to that used by switch-to-configuration.pl; that is, substitute occurrences of @systemd@ with ${config.systemd.package}, and then look for systemd's utilities relative to that substituted path. WDYT?

[Yarny0]

Reviewed points

• changes are backward compatible (compared to the situation before nixos/users-groups: add user option to enable lingering #260248)
• removed options are declared with mkRemovedOptionModule (not applicable here)
• changes that are not backward compatible are documented in release notes (not applicable here)
• module tests succeed on x86-64
• options types are appropriate
• options description is set
• options example is provided
• documentation affected by the changes is updated (none)

Possible improvements

• The mechanism does not work on bootup:

  stage-2-init: disabling lingering for user(s) 'user2'
  stage-2-init: System has not been booted with systemd as init system (PID 1). Can't operate.
  stage-2-init: Failed to connect to bus: Host is down

  Instead of calling loginctl, one might add/remove the files in /var/lib/systemd/linger directly, but I'm wondering if changing lingering settings in the activation script is a good idea at all: Can we even be sure that /var/lib/systemd/linger is avaliable in the initrd? It might get mounted later, by non-initrd systemd.

  Maybe it would be better to implement this as an ordinary systemd service:

  • It would have to run before logind, but after /var/lib/systemd/linger gets mounted (can be ensured with RequiresMountsFor=...).
  • It should be restarted on nixos-rebuild switch.
  • It would need to be able to control lingering with loginctl (if logind is already running), or by adding/removing files in /var/lib/systemd/linger by hand (if logind is not running yet).
  • As an ordinary system service, it would benefit from the parallelism of services at bootup.

• The test succeeds, but it should probably be listed in all-tests.nix. Given the problem at bootup, maybe we should also test a change of lingering settings at boot.

Comments

I strongly support this pull request: I have users that would like to control their lingering by themselves, and #260248 broke this. Also I like the trinary design of the option: It's quick and clear!

[tomeon]

@Yarny0 -- thanks for catching the boot-time issue. I've added fallback lingering management methods to update-users-groups.pl, and added cases to the user-lingering.nix test to exercise these routines on initial boot and on reboot. I've also added user-lingering.nix to all-tests.nix, so thanks for that as well.

Re managing user lingering in an activation script: I implemented it like that in order to hook into the existing user creation and deletion logic. I suppose it would be possible to make update-users-groups.pl write out a user lingering manifest to (say) /var/lib/nixos/user-lingering, along the lines of /var/lib/nixos/{auto-subuid-map,declarative-groups,declarative-users,gid-map,uid-map}. Though presumably this approach is susceptible to concerns about the presence of the file path at boot time and its persistence at later stages, as with /var/lib/systemd/linger. Other options include removing features (e.g. only managing user lingering when users.mutableUsers is disabled).

[aanderse]

purely informational but i'll mention #264879 as a landing point for you to look at - why? there are people who have intentions involving the scripts you're working on here

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/80