https://bugs.kde.org/show_bug.cgi?id=404335
--- Comment #32 from Gerald Cox <gb...@bzb.us> --- Here is a response from: https://bugzilla.redhat.com/show_bug.cgi?id=1912046 In case you didn't see it. I pushed a pull request to beef up systemd's docs a bit: https://github.com/systemd/systemd/pull/18137. It also deprecates a blanket 'systemctl import-environment' command and changes systemctl to emit a warning when that is used. It is fairly easy to describe how the environment is constructed by systemd, but the interaction with other parts of the stack is complex and not documented well. I don't think the systemd man pages are appropriate for this kind of documentation — we don't have the expertise and they would become stale at some point. We could probably put a document under systemd.io if no better place is found. > To dig a bit further, the memo says "Define shell-specific setup through > shell-specific profile scripts.", > but systemd goes through the shell-specific profile scripts. Systemd itself doesn't use the shell *at all*. This also means that it doesn't care about profile scripts. Instead, various desktop environments execute in an environment where the shell profile functions have been executed, and when they call 'import-environment' or the dbus-api equivalent to propagate session-specific variables, various variables are pushed to the manager environment block. I don't think this makes sense, because we end up with too many wrong things in the global environment. What I think should happen is that the desktop environment should export a few variables it sets itself (emphasize *itself* here, if the desktop environment is assigning a variable, it knows whether it belongs in the global session block): DESKTOP_SESSION, DISPLAY, GDMSESSION, GDM_LANG, GNOME_SETUP_DISPLAY?, SESSION_MANAGER?, WAYLAND_DISPLAY, XAUTHORITY, XDG_SESSION_*, or equivalent for other environments. Whenever a shell process is created for the user, it should execute shell profile functions and create set the shell-specific variables there. I'm not an expert in bash profile initialization, but it seems that the right thing happens already: when I clean up my systemd user environment block by removing e.g. all MODULE* variables, and start a shell process as a service, I get them back: $ systemd-run --user -t bash (nested) $ set|grep ^MODULE MODULEPATH=/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles MODULEPATH_modshare=/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1 MODULESHOME=/usr/share/Modules MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl MODULES_RUN_QUARANTINE='LD_LIBRARY_PATH LD_PRELOAD' When I start a gnome-terminal, the shell in the gnome terminal also has the MODULE* variables. So it seems that the environment-modules stuff is properly initialized without pushing anything through the manager environment block. I don't think there's anything to fix in environment modules. It's gnome-desktop/kde that might need some tweaking. -- You are receiving this mail because: You are watching all bug changes.
