The emacs.service systemd user service does not start the emacs daemon with the full user PATH. This leads to e.g. lsp-mode not being able to start clangd, because the clangd binary resides in /usr/lib/llvm/8/bin/clangd, which is added to the user's PATH via gentoo's env.d mechanism. Hence the emacs systemd service installed by the app-editors/emacs ebuild should evaluate /etc/profile.env before starting the emacs daemon.
I have created bug #704416 to ask for env-update to additionally create a systemd EnvironmentFile compatible equivalent of /etc/profile.env. Although this could be solved probably by other means also, e.g. modifying the service's ExecStart so that /etc/profile.env is parsed before starting emacs, using EnvironmentFile appears to be the best solution.
I cannot reproduce this, because I am not running systemd on any of my systems. The emacs ebuild simply installs the emacs.service file from upstream. So if there are any issues with it, please file a bug report upstream. (We can then backport their changes to Emacs 26 if necessary.)
(In reply to Ulrich Müller from comment #2) > The emacs ebuild simply installs the emacs.service file from upstream. So if > there are any issues with it, please file a bug report upstream. I do not think that this can be considered an upstream bug, as it strikes me being a Gentoo specific issue. It can not be easily handled by upstream in a generic Linux-distribution agnostic way. Only if distributions would agree on a common place for a systemd EnvironmentFile file holding the user environment. If such a file would exists, e.g., /var/lib/systemd/user.env, then projects like emacs could modify their shipped example systemd service file(s) to add EnvironmentFile=-/var/lib/systemd/user.env (the '-' prefix, which indicates that missing files will be ignored) Meanwhile I was able to modify the emacs ebuild to produce a systemd user service file which sources /etc/profile.env. The ExecStart configuration now reads: ExecStart=/bin/sh -c "source /etc/profile.env; exec /usr/bin/emacs-26 --fg-daemon" which is achieved by replacing the ExecStart sed expression in the ebuild with -e "s:^ExecStart=.*:ExecStart=/bin/sh -c \"source ${EPREFIX}/etc/profile.env; exec ${EPREFIX}/usr/bin/${EMACS_SUFFIX} --fg-daemon\":" patch attached. Please consider applying it.
Created attachment 602296 [details, diff] emacs ebuild patch to make the systemd service file source /etc/profile.env
(In reply to Florian Schmaus from comment #3) > I do not think that this can be considered an upstream bug, as it strikes me > being a Gentoo specific issue. [...] Well, systemd starts a process for the user, but fails to provide it with the user's environment. One could argue that not only profile.env should be sourced, but also /etc/profile and the user's ~/.profile (or their equivalent if the user is using some other shell than bash, like csh), because the user could modify the environment as well. This is not specific to Gentoo, but a general problem, so it should be solved upstream (systemd or Emacs). We had a similar problem with the openrc init script (in app-emacs/emacs-daemon), and solved it by starting the Emacs process from a wrapper script with the user's login shell. > ExecStart=/bin/sh -c "source /etc/profile.env; exec /usr/bin/emacs-26 --fg-daemon" See above, I won't apply such a partial solution. Please talk to upstream (either of them, or both) first. If they should also think that this is distro specific, then we can continue here.
(In reply to Ulrich Müller from comment #5) > Well, systemd starts a process for the user, but fails to provide it with > the user's environment. One could also argue that Gentoo fails to provide /etc/environment.d files for systemd, which would solve the issue (see bug #704416). > One could argue that not only profile.env should be > sourced, but also /etc/profile and the user's ~/.profile (or their > equivalent if the user is using some other shell than bash, like csh), I don't think that is sensible to run /etc/profile nor ~/.profile for every starting systemd user service. I, as user, would expect those to be run only exactly once on login, and not multiple times for every systemd user service. Running them multiple times at least introduces unnecessary overhead, and potentially even breaks things. > because the user could modify the environment as well. This is not specific > to Gentoo, but a general problem, so it should be solved upstream (systemd > or Emacs). I would not be surprised if systemd (and probably Emacs) upstream would tell me that this is already solved and point me to "man 5 environment.d" as solution for this. > > ExecStart=/bin/sh -c "source /etc/profile.env; exec /usr/bin/emacs-26 --fg-daemon" > > See above, I won't apply such a partial solution. Please talk to upstream > (either of them, or both) first. If they should also think that this is > distro specific, then we can continue here. I think it would be sensible to ably this partial solution until Gentoo becomes a mechanism which populates the systemd enviornment.d directory (via env-update).
(In reply to Florian Schmaus from comment #6) > One could also argue that Gentoo fails to provide /etc/environment.d files > for systemd, which would solve the issue (see bug #704416). There already is an established method for providing an environment, namely /etc/profile and ~/.profile. IMHO duplicating it makes little sense. > I don't think that is sensible to run /etc/profile nor ~/.profile for every > starting systemd user service. I, as user, would expect those to be run > only exactly once on login, and not multiple times for every systemd user > service. Running them multiple times at least introduces unnecessary > overhead, and potentially even breaks things. The overhead of sourcing these files is negligible, compared to startup time of Emacs itself.
With portage's The idiomatic solution appears to be that the user runs systemctl --user import-environment PATH after every PATH change of the user's environment. All *subsequently* started user units will have the PATH at the time of running that command. Now that 45a5982fe807 ("env-update: create systemd user-session environment definition") [1] and subsequent fixes are in place, there is not much more we can or should do here. 1: https://gitweb.gentoo.org/proj/portage.git/commit/?id=45a5982fe8076066323e91f6b5fe860f3a429f9f
