<div dir="ltr"><div class="gmail_quote"><div>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.</div><div><br></div><div>However, it seems to me that there would be quite some usecases that fall outside these where multiple sessions make sense:</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div><br></div><div>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?</div><div><br></div><div>Benno</div></div></div>