When useSystemdActivation is enabled, sops-install-secrets.service runs
ordered Before=sysinit-reactivation.target, which switch-to-configuration
restarts *after* it has already consumed /run/nixos/activation-*-list.
Writing to those files from the service therefore does nothing on the
current switch and leaks into the next one.
NixOS 26.05 also deprecates the activation-list mechanism, printing a
warning whenever the files exist, with removal planned for 26.11.
Detect systemd invocation via INVOCATION_ID and call systemctl directly
(try-restart / try-reload-or-restart, --no-block to avoid deadlocking
the sysinit transaction). The legacy activation-script path keeps
writing the list files for backward compatibility.
Followup for #765, where I missed this. It's needed here too, since it
runs in the same context as the default module.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
This fixes https://github.com/Mic92/sops-nix/issues/659
In https://github.com/Mic92/sops-nix/pull/649, we started rendering
templates twice:
1. When rendering `neededForUsers` secrets (if there are any
`neededForUsers` secrets).
2. When decrypting "regular" secrets.
This alone was weird and wrong, but didn't cause issues
for people until https://github.com/Mic92/sops-nix/pull/655, which
triggered https://github.com/Mic92/sops-nix/issues/659. The cause is not
super obvious:
1. When rendering `neededForUsers` secrets, we'd generate templates in
`/run/secrets-for-users/rendered`.
2. However, the `path` for these templates is in
`/run/secrets/rendered`, which is not inside of the
`/run/secrets-for-users` directory we're dealing with, so we'd
generate a symlink from `/run/secrets/rendered/<foo>` to
`/run/secrets-for-users/rendered/<foo>`, which required making
the parent directory of the symlink (`/run/secrets/rendered/`).
3. This breaks sops-nix's assumption that `/run/secrets` either doesn't
exist, or is a symlink, and you get the symptoms described in
<https://github.com/Mic92/sops-nix/issues/659>.
Reproducing this in a test was straightforward: just expand our existing
template test to also have a `neededForUsers` secret.
Fixing this was also straightforward: don't render templates during the
`neededForUsers` phase (if we want to add support for `neededForUsers`
templates in the future, that would be straightforward to do, but I
opted not do that here).
