On 24/11/2023 00:20, Greg Wooledge wrote:
For me, all of the environment.d(5) stuff goes into the systemd --user
service manager which spawns... nothing that's visible to me. Nothing
at all.
All of my visible applications (terminals, web browsers, etc.) are
spawned by my window manager, which is spawned by my X session, which
is spawned by startx, which is spawned by my console login shell, when
I type the "startx" command.
I guess you are not running Gnome. I am not surprised that environment.d
and /etc/profile and other shell settings are almost not connected in
your case. A window manager still might do some magic by calling
"systemctl set-environment". My impression is that nowadays an
application spawned by systemd is not something unusual.
- emacs.service (optional)
- Gtk and Qt application may activate various D-Bus services ("busctl
--user" to get list of ones ready to start)
- MIME type or URI scheme handlers advertised through .desktop files may
be invoked by GUI applications through D-Bus: "grep DBusActivatable
/usr/share/applications/*.desktop" see
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html#key-dbusactivatable
Certainly for particular set of application there may be almost no
systemd services. Alternatives may be available, e.g. XDG autostart is
implemented in KDE and Gnome using systemd user session, but other
window managers may invoke them directly.
Due to these reasons I would not neglect environment.d completely.
I experimented a bit with KDE and SDDM (I do not have a Gnome VM ready
for tests). Terminal applications (konsole, xterm) are started as
children of systemd user session, not startplasma that is spawned by the
display manager. So /etc/environment.d and ~/.config/environment.d
*affect* environment of shell in terminal applications.
On the other hand I can not say that I understand what happens with
PATH. Likely modifications made through environment.d are overwritten by
/etc/profile. The latter is called by /etc/sddm/Xsession (or
wayland-session).
Another observation is that /etc/profile settings (besides PATH!) do not
affect "systemctl --user show-environment", but the same settings are
present in children processes of systemd obtained using
tr '\0' '\n' </proc/$PID/environ
Fluxbox session has both trees: systemd and window manager.
environment.d does not affect terminals launched by fluxbox.
(fbautostart was not installed.)
I am puzzled why neither environment.d nor /etc/profile works in the
case of the topic starter. I suspect a typo somewhere. I am unsure if
various bugs like https://github.com/systemd/systemd/issues/6414 are
relevant.
Just a reminder: BASH does not read ~/.profile if ~/.bash_login or
~/.bash_profile exists.
Greg, do you have ideas how to relieve pain with environment configuration?
E.g. to not override pam_environment by PATH hardcoded in /etc/profile, to
negotiate what files display managers should read, etc.
Didn't I just post a long message about this?
You post is great in respect to details concerning current state of
affairs. I tried to ask if you see a way to make configuration easier
for users. E.g. /etc/profile is suitable when a shell is involved. It
was fine decades ago, but display managers may start sessions bypassing
shells. Perhaps environment.d may be sourced by shells in the case of
console login and xinit. I still hope that it is possible to create a
single point for environment configuration and to provide helper tools
for various ways to login.
