[systemd-devel] Systemd --session instance?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 24, 2017 at 08:09:00PM +0000, Benno Fünfstück 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.
> 
> 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?

> * 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.

Increased complexity in *all* software — each and every thing you start must
support multiple sessions.

Anyway, it's something that could be discussed until the heat death of
the universe. If you think this can work, add support to the DE of
your choice, build a bunch of unit files, and convince maintainers of
various programs to add necessary support (firefox, thunderbird,
libreoffice, and anything else which keeps nontrivial state). I think
it's fair to say that people on this list think that this goal is not
worth pursing.

Zbyszek