NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.07k stars 14.08k forks source link

Systemd units associated with packages don't get picked up #42434

Open michaelpj opened 6 years ago

michaelpj commented 6 years ago

Issue description

Evince, for example, has a systemd user service in $out/lib/systemd/user. This runs evinced, which is a daemon that it does something with. Currently, it can't find the service because the unit file gets installed to /run/current-system/sw/lib/systemd/user, which isn't somewhere systemd looks for units.

Ideally this would also work for packages installed with nix-env, so ~/.nix-profile/lib/systemd/user should also be checked.

Here's the list of places systemd looks for user units according to the man page:

Path Description
$XDG_CONFIG_HOME/systemd/user.control or ~/.config/systemd/user.control Persistent and transient configuration created using the dbus API ($XDG_CONFIG_HOME is used if set, ~/.config otherwise)

$XDG_RUNTIME_DIR/systemd/user.control /run/systemd/transient | Dynamic configuration for transient units /run/systemd/generator.early | Generated units with high priority (see early-dir in system.generator(7)) $XDG_CONFIG_HOME/systemd/user or $HOME/.config/systemd/user | User configuration ($XDG_CONFIG_HOME is used if set, ~/.config otherwise) /etc/systemd/user | Local configuration $XDG_RUNTIME_DIR/systemd/user | Runtime units (only used when $XDG_RUNTIME_DIR is set) /run/systemd/user | Runtime units $XDG_RUNTIME_DIR/systemd/generator | Generated units with medium priority (see normal-dir in system.generator(7)) $XDG_DATA_HOME/systemd/user or $HOME/.local/share/systemd/user | Units of packages that have been installed in the home directory ($XDG_DATA_HOME is used if set, ~/.local/share otherwise) $dir/systemd/user for each $dir in $XDG_DATA_DIRS | Additional locations for installed user units, one for each entry in $XDG_DATA_DIRS /usr/local/lib/systemd/user | Units of packages that have been installed system-wide /usr/lib/systemd/user $XDG_RUNTIME_DIR/systemd/generator.late | Generated units with low priority (see late-dir in system.generator(7))

Perhaps the simplest thing is to add those directories to XDG_DATA_DIRS? I don't know whether that would have any undesirable side-effects...

Steps to reproduce

Technical details

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

michaelpj commented 6 years ago

I think adding /lib to XDG_DATA_DIRS in environment.profileRelativeEnvVars should do it.

michaelpj commented 6 years ago

That didn't work - perhaps it's not set early enough for systemd?

michaelpj commented 6 years ago

Well, systemd-analyze --user unit-paths seems to think it should pick it up, but even after a systemd --user daemon-reload it does not. Not sure what's going on here.

symphorien commented 6 years ago

I think you are supposed to put evince in the systemd.packages option: https://nixos.org/nixos/options.html#systemd.packages

michaelpj commented 6 years ago

Hm, that seems awkward, and only works for things integrated via the module system. I don't see an obvious a priori reason why we shouldn't just pick up user units for packages installed via nix-env too...

michaelpj commented 6 years ago

For example, I installed evince normally and had no idea it had a systemd component until I randomly saw it in the journal. It seems hard for users to discover that they need to do this.

michaelpj commented 6 years ago

Related: https://github.com/NixOS/nixpkgs/issues/19110

Ekleog commented 6 years ago

(triage) Do I understand correctly and this is about nix-env installing systemd packages? If so, this should be opened against the nix issue tracker. But TBH I don't really think it'd be a good idea, as nixos system management is designed to be reproducible and nix-env wouldn't really allow it, so I would guess this would be closed.

As for #19110, it appears to be about the related issue of unifying (or not) environment.systemPackages and systemd.packages.

michaelpj commented 6 years ago

Installing packages with nix-env already adds plenty of data files that get picked up by the system, since ~/.nix-profile is in XDG_DATA_DIRS. This seems fine to me, and I don't see why systemd user units are any different. They're self-contained, will reference executables in the nix store (which is fine), and are isolated to that user.

Looking at it again, the problem is actually about installing the files in the right place. We actually do install the files at the moment, but they end up in ~/.nix-profile/lib/systemd/user or /run/current-system/sw/lib/systemd/user, and those lib folders aren't in XDG_DATA_DIRS (which for us is the share subdirectory). Not entirely sure what should be done about that other than putting the lib subdir in XDG_DATA_DIRS, which seems wrong. (This is noted in the linked issue)

Ekleog commented 6 years ago

My reading of the linked issue is that it states that the files should not be linked to /run/current-system/sw/lib/systemd/user.

And I think home-manager provides an equivalent of systemd.packages, which handles the question at the user level, and thus that this issue is exactly a duplicate of #19110.

Now, you may disagree with the outcome of the discussions in #19110, but then I'd think your best chance to get something changed is to close this take the question there :)

michaelpj commented 6 years ago

I disagree that this is home-manager's problem at the user level any more that all the other stuff that nix-env installs is home-manager's problem.

IMO systemd.packages is just a bug.

I can close this issue, but I think it's helpful to have it here since the other issue doesn't describe the problem that arises, but rather the underlying cause, so this is useful for people who might hit the same problem.

arianvp commented 5 years ago

Is this on NixOS? we use a patched systemd that looks for unit files in non-standard locations. And it even already looks for units in the profile, just only in the default profile https://github.com/systemd/systemd/commit/9cfa7fb2cf17818f64e73c39f9389ca2d1462440

So, if you install as sudo nix-env -iA evince instead of nix-env -iA evince then systemd should pick it up. Given we already have a precedent of looking for unit files in the default profile, I don't see why we wouldn't allow looking them up in different profiles as well.

Though, I'm pretty sure this part of our systemd fork is heavily undocumented and seems to be mostly superseded by new nixos code that builds the /etc/systemd/system folder instead

stale[bot] commented 4 years ago

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse.
  3. Ask on the #nixos channel on irc.freenode.net.