1

Desktops such as GNOME have moved processes from the per-session scope, into the per-user systemd manager (systemd --user). This includes GUI apps such as GNOME Terminal.

What does GNOME use the systemd user manager to achieve? Is there a rationale somewhere I can read?


GNOME appears to copy the environment variables of the session into the user manager. Note that GNOME does not support the user logging in more than once at the same time. These environment variables include, intentionally or not, XDG_SESSION_ID.

loginctl, as in loginctl lock-session, ended up being modified to support this second, less well-defined concept of a session.

I'm curious what prompted people to create this strangeness.

sourcejedi
  • 50,249
  • Background questions are https://unix.stackexchange.com/questions/323663/ and https://unix.stackexchange.com/questions/201900/ . – JdeBP Sep 18 '17 at 10:27

2 Answers2

2

There are a number of benefits to this, but the primary one is to place each application in its own kernel cgroup. This allows gnome-shell to do application matching more reliably, and one can use resource controls to (for example) say Epiphany only gets 20% of system RAM.

Furthermore, this lays some fundamental groundwork for application sandboxing.

https://wiki.gnome.org/ThreePointThirteen/Features/SystemdUserSession

I can understand GNOME being interested in CGroups. Systemd provides an existing framework for this.

I didn't find any rationale for KDE Plasma doing this in my searching. The closest I came was

My idea so far is that a Plasma on Wayland shell needs to be brought up by systemd. Especially I consider using socket activation to start the KWin session compositor.

https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/GMtZrNCeaLD

but there was no explanation why socket-activating KWin makes sense when it's essential for a Plasma session.


I haven't looked at why systemd killed off systemd --session and enshrined systemd --user in pam_systemd. Maybe a per-session instance would have been a cleaner system in principle, but I'm not sure. I expect there was some practical reason that made it not quite as attractive.

sourcejedi
  • 50,249
2

There's an updated explanation. Reported benefits include:

  • Allowing some things to be started only as needed, like XWayland or a smart card service
  • applying resource constraints to memory and CPU to services.

For this already familiar with systemd, this means a more a standardized and consistent way to do things like start, stop and disable services, set environment variables for apps and view and manage logs for specific services.

Personally, I wasn't familiar with how all the Gnome session pieces were managed before but I'm familiar with systemd so this will make my desktop easier to understand and manage.

sourcejedi
  • 50,249