Open michaelpj opened 6 years ago
I think adding /lib
to XDG_DATA_DIRS
in environment.profileRelativeEnvVars
should do it.
That didn't work - perhaps it's not set early enough for systemd?
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.
I think you are supposed to put evince in the systemd.packages
option: https://nixos.org/nixos/options.html#systemd.packages
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...
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.
(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
.
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)
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 :)
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.
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
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:
Issue description
Evince, for example, has a systemd user service in
$out/lib/systemd/user
. This runsevinced
, 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:
$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.