bug: systemd services do not work when setting xdg.configHome

MithicSpirit commented 3 months ago

Are you following the right branch?

[X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

[X] I have searched the existing issues

Issue description

If xdg.configHome is set to something other than the default (~/.config), then systemd stops working because it looks in ~/.config anyway. I've tried telling it about the new $XDG_CONFIG_HOME multiple ways, but none of them work.

dbus-update-activation-environment --systemd XDG_CONFIG_HOME (presumably because systemd doesn't realize to look in the new $XDG_CONFIG_HOME when it's set after it's already loaded)
systemd.user.sessionVariables = config.home.sessionVariables (this writes a file to ${xdg.configHome}/environment.d/10-home-manager.conf, which systemd doesn't know to look for until it's had $XDG_CONFIG_HOME set, which won't happen until the file is loaded, so we get a circular dependency)
pam.sessionVariables = config.user.sessionVariables (this seems to create ~/.pam_environment just fine, but it's just not getting loaded for whatever reason; also, this option is deprecated so not an ideal solution regardless)

Maintainer CC

@rycee @veehaitch (pam)

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.9.2, NixOS, 24.05 (Uakari), 24.05.20240531.805a384`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/i1aw9jjgxcvyd642s12kw3iasmarwd42-source`

MithicSpirit commented 3 months ago

I was able to work around this by setting

  systemd.services."user@${toString config.users.users."<name>".uid}" = {
    environment = builtins.mapAttrs (_: toString)
      config.home-manager.users."mithic".home.sessionVariables;
    overrideStrategy = "asDropin";
  };

in my system configuration. I'm not sure whether there's any way to do this within just home-manager due to limitations with systemd (see Arch Wiki/Systemd/User#Environment variables).

As for pam.sessionVariables, the issue seems to be that user_readenv=0 is the default for pam_env.so, so it wasn't getting loaded. Since this has been deprecated upstream, it's not an appropriate solution anyway. Sorry for bothering you @ veehaitch.

nbraud commented 3 months ago

@MithicSpirit I honestly doubt HM can cope with a non-default xdg.configHome in a sensible way without being integrated with the overall system. I think a sensible solution for HM's NixOS module would be to add xdg.configHome to the manager's environment, and rely on user-level mechanisms to set the services' default environment (presumably via systemd.user.settings.Manager.DefaultEnvironment, see #5542)

I suspect that it would be more awkward to deal with changes if the whole environment is passed via the system-level user@${uid}.service unit, as changes wouldn't be picked up by systemctl --user daemon-reload.

nbraud commented 3 months ago

Actually, this can't work in the general case, as users' ids aren't necessarily known in the NixOS config >___>'

This would have to be instead something which generates the drop-in config before systemd loads (and starts) units, either in a generator or in a NixOS activation script. systemd generators are automatically re-run when reloading unit definitions, so either should be fine.

PS: Thinking more about it, this isn't the only issue: the drop-in should also introduce a dependency of user@${uid} on home-manager-${name}, for systemd-user.conf to be in place.

stale[bot] commented 2 days ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

nix-community / home-manager