[systemd-devel] Systemd --session instance?

[Lennart Poettering]

On Mon, 24.04.17 20:09, Benno Fünfstück (benno.fuenfstueck at gmail.com) wrote:

> Thank you Lennart for taking the time to answer my question. It does make
> sense that you wouldn't want to support multiple sessions in big desktop
> environments like Gnome or KDE or any complex software.
> 
> However, it seems to me that there would be quite some usecases that fall
> outside these where multiple sessions make sense:
> 
> * first, while most software may not support multiple *graphical* sessions,
> it would be nice to be able to isolate my non-graphical sessions (like tty
> or ssh or whatever) from the, perhaps single, graphical session. As it
> stands, if I want to use systemd for managing graphical daemons, I have to
> import things like DISPLAY into the systemd --user instance which feels
> wrong to me, as there may be many other user services that do not rely on
> that variable at all and should not care.

Multiple per-user text sessions should be supported just fine. All we
changed is that we now put the focus on a single graphical session per
user at a time.

> * second, you say that big, complex software does not support multiple
> sessions sanely. However, I feel like this is a feature that would be most
> used by people running very lightweight graphical sessions. For example, I
> currently start my graphical services in `.xinitrc`. It would be very nice
> to be able to use systemd for this, as that would allow me to sanely stop
> all daemons at logout time.
> 
> I understand that for most users this feature may not be strictly
> necessary. There is a cost associated with maintaining this in systemd. But
> couldn't most of the code be shared with systemd user support? Or are there
> any other costs that I'm overlooking, apart from the increased complexity &
> maintenance cost to the systemd codebase?

Well, the difference between "systemd --user" and "systemd --system"
is dominantly one of search paths: where to look for unit files and
other resources: /usr/lib/systemd/system vs. /usr/lib/systemd/user and so on. If you now
introduce a third set of search paths /usr/lib/systemd/session, then
you'll open an entirely new can of worms, as no apps install their
unit files there, and you'd have to convince every single one of them
to do so now too, and understand the complexity this involves, and the
thin, vague difference between being called from --user and --system.

So, sorry, but this would have massive implications on the entire app
ecosystem, and I am very sure this isn't worth it. Sorry!

Lennart

-- 
Lennart Poettering, Red Hat