https://bugs.kde.org/show_bug.cgi?id=505529
Bug ID: 505529
Summary: The handling of environment variables of
startplasma-wayland is broken
Classification: Plasma
Product: plasmashell
Version First 6.3.5
Reported In:
Platform: unspecified
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: Startup process
Assignee: plasma-b...@kde.org
Reporter: alvisebruni...@gmail.com
CC: k...@davidedmundson.co.uk
Target Milestone: 1.0
SUMMARY
I recently had difficulties trying to configure my PATH variable in a
shell/de-agnostic way, and did some digging into how plasma handles variables.
I might not be 100% correct (feel free to correct me), but here is how i
understand it, and why I think it's broken. Also, this involves SDDM, not only
plasma. I'm also not entirely sure this is the right place for this.
In a standard setup, SDDM runs the `wayland-session` script which does some
sourcing of /etc/profile and ~/.profile (or *sh-equivalent) than starts
`startplasma-wayland`.
`startplasma-wayland` used dbus to start the `plasma-core.target` systemd unit
which depends on various other units.
Now, these services are started by the user's systemd session, they are not
children of `startplasma-wayland`, which means they won't inherit it's
environment. and they aren't even children of a single `plasma-core.target`,
they only get the environment that systemd provides them. To escape this
situation `startplasma-wayland` (before starting the target unit) uses dbus to
add its variables to the user's systemd session's environment variables, which
will then be inherited by all future user services (including plasma).
This is problematic because systemd already has a way for the user to configure
environment variables for user services, which are environment generators
(https://www.freedesktop.org/software/systemd/man/latest/systemd.environment-generator.html)
and in particular systemd-environment-d-generator is especially useful
(https://www.freedesktop.org/software/systemd/man/latest/systemd-environment-d-generator.html).
The `startplasma-wayland` solution will override all variables that are present
both in the profile sourced by `wayland-session` and the generator, this always
includes the PATH variable which cannot be set from a generator, or it will be
overwritten by plasma.
Moreover, these variables are inherited by all of the user's services, but only
those that by chance started after plasma, so the user ends up with some
services with an old variables, and some others with the overwritten ones.
A simple workaround that I'm employing is to add an `eval "$(systemctl --user
show-environment)"` in the `wayland-session` script that fetches the user's
systemd variables before the profile is sourced, so that both systemd and
profile can modify the effective variables (i.e. adding paths to PATH). but
this is not optimal because the profile can still override any variable and
propagate it to any future user service.
Some better solutions might be (assuming we are already systemd dependant if we
are using dbus to start plasma):
- dropping the `startplasma-wayland` script and reimplement its functionality
as an environment generator
- pro: profiles are always sourced, and systemd variables are always taken
into account, the user can even decide the order of sourcing
- con: still propagated to every user service
- have the plasma components source the profile, instead of
`startplasma-wayland`
- pro: less amount of work, nothing else needs to change
- con: depending on the implementation the profile might be sourced multiple
times
- have a plasma-environment-daemon that can be interrogated over dbus that
sources/receives and holds all the variables (I personally like this one)
- pro: variables are consistent, and limited to the plasma session (not all
services)
- con: another component to write and maintain
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.1
Kernel Version: 6.14.9-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7700X 8-Core Processor
Memory: 30.9 GiB of RAM
Graphics Processor: AMD Radeon RX Vega
--
You are receiving this mail because:
You are watching all bug changes.
