Re: [systemd-devel] Systemd --session instance?
On Tue, 25 Apr 2017 at 09:55:16 +0200, Lennart Poettering wrote: > 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! This is essentially the same argument as the reason why `dbus-daemon --session` can be configured (by a distro or sysadmin) to be one per login session, or one per `systemd --user`, but never both at the same time. Having both exist at the same time (a "user bus" *and* a per-login-session bus) would just be too confusing, and everyone would use the wrong one. If a particular service does want to exist once per login session or once per X11 display, instanced services (`xwallpaper@:0.service`) are one possible solution. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
On Mon, 24.04.17 20:09, Benno Fünfstück (benno.fuenfstu...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
> > Increased complexity in *all* software — each and every thing you start > must > support multiple sessions. > Oh, why is that? I wasn't suggesting to replace the existing systemd --user instance, only to add a new one for each session. So software that does not support multiple sessions still does not have to: if firefox does not support multiple sessions, then so be it, then that means you can only use it on a single session and it continues to use the per-user instance. Or is it not that easy? Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
On Mon, Apr 24, 2017 at 08:09:00PM +, 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
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. * 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? Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
On Sat, 22.04.17 14:07, Benno Fünfstück (benno.fuenfstu...@gmail.com) wrote: > Hello list, > > currenty, systemd runs a system instance and a per-user one. However, > sometimes it would be nice to have a per-session instance, for example for > users of lightweight desktop environments that don't have their own service > manager. Then you could use systemd to spawn things like panels or desktop > notification daemons etc. Would it be possible to add such a thing, even if > it may require some work? Or are there any fundamental problems with it? As Zbigniew already pointed out this was a deliberate design decision not to support. In the general case software can't really deal with multiple sessions of the same users. Some fail in friendlier ways (for example, web browsers tend to take a lock at startup thus ensuring they are only started once per user) and others in unfriendlier ways. Yes, there are select few programs which are entirely fine with running multiple times for the same users, but these tend to be the exception, not the rule, and are usually on the more simple side of things, with anything more complex not supporting it. The idea of moving to a single-graphical-session-per-use scheme doesn't mean you are restricted to a single screen however. It just means every hw you have (be it a kbd, a screen, a mouse, ...) would be merged in one way or another into a single session. (i.e. in a xinerama-style setup)... After all, between a user and himself sharing should be a good thing, not a bad thing. Yes, this is not how X11 used to handle things, but I figure what we can learn from history is that multiple sessions per user is too hard, and too exotic for app developers to implement it correctly. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
On Sun, Apr 23, 2017 at 06:19:16PM +, Benno Fünfstück wrote: > > > > On Sat, Apr 22, 2017 at 02:07:49PM +, Benno Fünfstück wrote: > > > Hello list, > > > > > > currenty, systemd runs a system instance and a per-user one. However, > > > sometimes it would be nice to have a per-session instance, for example > > for > > > users of lightweight desktop environments that don't have their own > > service > > > manager. Then you could use systemd to spawn things like panels or > > desktop > > > notification daemons etc. Would it be possible to add such a thing, even > > if > > > it may require some work? Or are there any fundamental problems with it? > > > > It would require a fundamental amount of work. We (people developing > > systemd, large graphical environments, dbus, ...) to move towards > > user-sessions, > > and limit support to one graphical session per user. The thinking is that > > one graphical session is enough for one user. > > > > In principle you could still have a single systemd --user instance, > > and e.g. start various services multiple times using templating > > (terminal-daemon@.service, file-manager@.service, etc). This isn't too > > hard to get working in a limited scope, but making it work in general > > is hard, and would require a lot of support from various > > programs. Your use case would be neat, but also a bit fringe, and it's > > complicated enough to get graphical envs working with one session per > > user. > > > > Zbyszek > > > > Thanks for the answer! Can you go into some more detail about what > particular challenges there are with making such a thing possible? (Just > some, because currently I feel like it would be easy and I would like to > get a feeling for the kind of problems this would cause / would have to be > dealt with) It's not my idea of expertise. Basically you have to ensure that every program and every service you start is aware of multiple sessions. There is no privilege separation like with different users, and there is no issue until you actually start multiple sessions, so it's very easy to get this wrong. Somebody else might speak up, but I think you'll need to do your own search of the archives. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
> > On Sat, Apr 22, 2017 at 02:07:49PM +, Benno Fünfstück wrote: > > Hello list, > > > > currenty, systemd runs a system instance and a per-user one. However, > > sometimes it would be nice to have a per-session instance, for example > for > > users of lightweight desktop environments that don't have their own > service > > manager. Then you could use systemd to spawn things like panels or > desktop > > notification daemons etc. Would it be possible to add such a thing, even > if > > it may require some work? Or are there any fundamental problems with it? > > It would require a fundamental amount of work. We (people developing > systemd, large graphical environments, dbus, ...) to move towards > user-sessions, > and limit support to one graphical session per user. The thinking is that > one graphical session is enough for one user. > > In principle you could still have a single systemd --user instance, > and e.g. start various services multiple times using templating > (terminal-daemon@.service, file-manager@.service, etc). This isn't too > hard to get working in a limited scope, but making it work in general > is hard, and would require a lot of support from various > programs. Your use case would be neat, but also a bit fringe, and it's > complicated enough to get graphical envs working with one session per > user. > > Zbyszek > Thanks for the answer! Can you go into some more detail about what particular challenges there are with making such a thing possible? (Just some, because currently I feel like it would be easy and I would like to get a feeling for the kind of problems this would cause / would have to be dealt with) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
On Sat, Apr 22, 2017 at 02:07:49PM +, Benno Fünfstück wrote: > Hello list, > > currenty, systemd runs a system instance and a per-user one. However, > sometimes it would be nice to have a per-session instance, for example for > users of lightweight desktop environments that don't have their own service > manager. Then you could use systemd to spawn things like panels or desktop > notification daemons etc. Would it be possible to add such a thing, even if > it may require some work? Or are there any fundamental problems with it? It would require a fundamental amount of work. We (people developing systemd, large graphical environments, dbus, ...) to move towards user-sessions, and limit support to one graphical session per user. The thinking is that one graphical session is enough for one user. In principle you could still have a single systemd --user instance, and e.g. start various services multiple times using templating (terminal-daemon@.service, file-manager@.service, etc). This isn't too hard to get working in a limited scope, but making it work in general is hard, and would require a lot of support from various programs. Your use case would be neat, but also a bit fringe, and it's complicated enough to get graphical envs working with one session per user. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd --session instance?
Hello list, currenty, systemd runs a system instance and a per-user one. However, sometimes it would be nice to have a per-session instance, for example for users of lightweight desktop environments that don't have their own service manager. Then you could use systemd to spawn things like panels or desktop notification daemons etc. Would it be possible to add such a thing, even if it may require some work? Or are there any fundamental problems with it? Thanks, Benno Fünfstück ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
