| Summary: | The handling of environment variables of startplasma-wayland is broken | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | edinbruh <alvisebruniera> |
| Component: | Startup process | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | dennis.lissov, jannik.glueckert, john.kizer, kde, kde, m.kurz, nate, sam |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=491579 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
edinbruh
2025-06-12 15:49:19 UTC
Hello! You've reached the KDE bug tracker, which is for tracking and investigating specific bugs. Unfortunately I cannot pinpoint a specific user-facing bug that's being reported here. Can you please read https://community.kde.org/Get_Involved/Issue_Reporting and add more information here as requested in the bug report template, like Steps to Reproduce the issue you observed, what result you saw, and what result you expected? If this is not a report of a specific user-facing bug, but instead a broader, general development proposal, then I'd recommend closing this bug report and posting as a topic at https://discuss.kde.org/ for discussion. Thanks! (In reply to John Kizer from comment #1) > Hello! You've reached the KDE bug tracker, which is for tracking and > investigating specific bugs. Unfortunately I cannot pinpoint a specific > user-facing bug that's being reported here. Can you please read > https://community.kde.org/Get_Involved/Issue_Reporting and add more > information here as requested in the bug report template, like Steps to > Reproduce the issue you observed, what result you saw, and what result you > expected? > > If this is not a report of a specific user-facing bug, but instead a > broader, general development proposal, then I'd recommend closing this bug > report and posting as a topic at https://discuss.kde.org/ for discussion. > > Thanks! For me, I see this as a bug, so I'm adding the required info in this comment. Steps to reproduce: 1. Try to edit the path in `~/.config/environment` adding `PATH=${PATH}:/path1` 2. Also add a fresh test variable `FOO=bar` 3. Edit the path in your profile (`~/.bashrc`, `~/.profile`, `/etc/profile`, doesn't matter) with `PATH=$PATH:/path2` 4. Also add a second fresh test variable `FIZZ=buzz` 5. Have some user service start at boot using `WantedBy=default.target` in its unit, for testing purpose 6. Reboot your system Expected result: * Plasma itself and applications should see: * either `PATH=$PATH:/path1:/path2` or `PATH=$PATH:/path2:/path1` (possibly the first) * `FOO=bar` * `FIZZ=buzz` * All user services should see "at least": * `PATH=$PATH:/path1` * `FOO=bar` * (Optionally, some user services may see the same variables as plasma) * This is to say that if some user services see more than the variable in `~/.config/environment` it's not a big deal Observed result: * Plasma itself and applications see: * `PATH=$PATH:/path2` * `FOO=bar` * `FIZZ=buzz` * User services started before plasma see: * `PATH=$PATH:/path1` * `FOO=bar` * User services started after plasma see: * `PATH=$PATH:/path2` * `FOO=bar` * `FIZZ=buzz` I'll have to defer to more experienced triagers/maintainers on whether this fits as a bug - FWIW it does seem like that procedure below differs from the recommended one at https://userbase.kde.org/Session_Environment_Variables (In reply to John Kizer from comment #3) > I'll have to defer to more experienced triagers/maintainers on whether this > fits as a bug - FWIW it does seem like that procedure below differs from the > recommended one at https://userbase.kde.org/Session_Environment_Variables Thanks for the quick reply. To ease the triaging, I'll try to explain why I still think its a problem, despite having an explicitly recommended procedure. Yes, it differs from that procedure, but it is still the procedure to globally set variables for systemd user services. So if kde simply didn't get the variable from `~/.config/environment`, it would have been fine, just mildly annoying. But because it actually messes up the variables for other services (as shown in the previous comment) I would still consider it a bug. As such, because startplasma-wayland is already using systemd to start the user session, it would be nice if it didn't fight against systemd variables, but instead bought into the variable handling system. For example but not necessarily, like I explained in the summary. Then, if the final user still wants to source their shell profile, they can still do it by adding a sourcing script as in the procedure you posted, instead of having the shell sourcing forced upon them by the administrator. Basically the whole thing just gives more control to the final user. Moreover, the recommended procedure is nothing more than a kde specific sourcing path, which means that as soon as one changes DE, they have to port everything over, the same goes for sourcing the shell, as soon as the user changes shell they must do all over again. Instead, systemd is ubiquitous and DE agnostic. And even on systems without systemd, the init system will offer some way of setting up the environment. An even if everything fails, then the kde specific sourcing path is still a viable fallback. I can confirm this issue, let me summarize why this is a real bummer: Systemd provides various facilities for packages, system administrators, and users to customize the user env. Namely simple snippets in environment.d and env generators (used by flatpak, for example). However, this is only active once the user session starts. startplasma-wayland, however, obviously starts outside of the session via sddm. This means that startplasma-wayland If I understand https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma-wayland.cpp correctly, startplasma-wayland basically does: 1. eval plasma-workspace/env scripts 2. set some misc required env vars like XDG_SESSION_TYPE 3. export this env into the systemd session - roughly equivalent to `systemctl --user import-environment` 4. re-import the env from the systemd session, and use this for the desktop session This is completely broken though. It means that the env that startplasma-wayland was launched with will always override env vars set through the standardized systemd mechanisms. Namely, we can't set PATH now, since the original startplasma-wayland env certainly has this set. I think plasma should do something like: 1. set known constant envs in the systemd session (such as XDG_SESSION_TYPE) 2. import the systemd session. 3. run plasma-workspace/env scripts 4. export the updated env to the systemd session For now, I'll just have to run plasma-workspace with this env export patched out :/ https://bugs.kde.org/show_bug.cgi?id=491579 has another (probably better) explanation of the current env procedure in startplasma |