Re: [systemd-devel] Per session systemd?
Hi On Mon, Mar 3, 2014 at 8:30 AM, Yuxuan Shui yshu...@gmail.com wrote: Hi, This mail might be a little bit later for the topic, but I would like to share my thoughts anyway. Before systemd 206 was released, there are a few users (I don't know how many of them are there, but there's a page about it on archlinux's wiki. So I guess it's a well-known use case.) who use systemd to manage their sessions. For example, they will exec systemd in their ~/.xinitrc, and have systemd start all their X applications. systemd --user ist started by PAM for any proper user login. So you could fix that by just using a proper login manager (if you don't want the big ones, there's small stuff like 'slim', too). Even if you don't want these, I still recommend to do a PAM authentication in your startup script. This might even be via pam_rootok so you don't have to enter any password. I know this kind of use case has never been explicitly supported by systemd, but it was a really nice _accidental_ feature. However, after the cgroup changes made in the systemd 206 release, it became impossible to use systemd in such way. I saw some user complaints, but the systemd developers seemed unmoved. Maybe because the original purpose of systemd --user is to start per-user systemd instances. There're hacks to make systemd usable under a X session. But that's very complicated, and contains many pitfalls (User have to set a lot of environmental variables, and this makes logind unhappy since the systemd user instance is not in the same session as X). Besides, there're reasonable use cases which can't be covered by a per-user systemd instance, like periodically starting a graphic application. Why is that not possible with per-user instances? So, I wrote a very dirty hack for my systemd, and have been using it till today. I add a 'User=' property to a session, and have systemd chown the cgroup to the given user, so I can start systemd in my .xinitrc as I used to. I admit this is probably a very bad hack, and I'm not sure if it will still work after the soon coming cgroup rework. That's why I'm writing this mail. I want to point out the reason behind use systemd as a session manager, so you will probably understand why I want to do this and help me. Since I can't get this done by myself with my limited systemd knowledge. Any help will be appreciated. It will be better if you can convince me that I'm stupid and this feature is totally useless. What's the problem with per-user systemd besides startup synchronization? (which is fixed by pam..) Our concept basically boils down to treating sessions as a banal ref-count to a user. Instead of putting all the big stuff into a session, we now move it to the user. You can still have multiple sessions, but they share the bulk of data now. On the one hand, this is required for stuff like firefox that can only run once per user. On the other hand, it seems rather natural to share contexts between multiple logins of the same user. The same 'user' cannot sit in front of two machines at the same time, so why allow two independent logins? Anyhow, there's a lot going on right now and it'll take some time until this is all implemented. But so far, there haven't been any use-cases that cannot be solved with per-user systemd. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per session systemd?
Hi, On Mon, Mar 3, 2014 at 4:11 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Mon, Mar 3, 2014 at 8:30 AM, Yuxuan Shui yshu...@gmail.com wrote: Hi, This mail might be a little bit later for the topic, but I would like to share my thoughts anyway. Before systemd 206 was released, there are a few users (I don't know how many of them are there, but there's a page about it on archlinux's wiki. So I guess it's a well-known use case.) who use systemd to manage their sessions. For example, they will exec systemd in their ~/.xinitrc, and have systemd start all their X applications. systemd --user ist started by PAM for any proper user login. So you could fix that by just using a proper login manager (if you don't want the big ones, there's small stuff like 'slim', too). Even if you don't want these, I still recommend to do a PAM authentication in your startup script. This might even be via pam_rootok so you don't have to enter any password. Yea, I know that. The problem is this instance is started once per every user. And this systemd instance don't belong to the same session as the logged-in user, causing problems I described below. I know this kind of use case has never been explicitly supported by systemd, but it was a really nice _accidental_ feature. However, after the cgroup changes made in the systemd 206 release, it became impossible to use systemd in such way. I saw some user complaints, but the systemd developers seemed unmoved. Maybe because the original purpose of systemd --user is to start per-user systemd instances. There're hacks to make systemd usable under a X session. But that's very complicated, and contains many pitfalls (User have to set a lot of environmental variables, and this makes logind unhappy since the systemd user instance is not in the same session as X). Besides, there're reasonable use cases which can't be covered by a per-user systemd instance, like periodically starting a graphic application. Why is that not possible with per-user instances? Yes, it's possible, but it has many pitfalls as I described. Here I mean if you *don't use those hacks*, you can't do things like periodically starting a graphic application So, I wrote a very dirty hack for my systemd, and have been using it till today. I add a 'User=' property to a session, and have systemd chown the cgroup to the given user, so I can start systemd in my .xinitrc as I used to. I admit this is probably a very bad hack, and I'm not sure if it will still work after the soon coming cgroup rework. That's why I'm writing this mail. I want to point out the reason behind use systemd as a session manager, so you will probably understand why I want to do this and help me. Since I can't get this done by myself with my limited systemd knowledge. Any help will be appreciated. It will be better if you can convince me that I'm stupid and this feature is totally useless. What's the problem with per-user systemd besides startup synchronization? (which is fixed by pam..) Our concept basically boils down to treating sessions as a banal ref-count to a user. Instead of putting all the big stuff into a session, we now move it to the user. You can still have multiple sessions, but they share the bulk of data now. On the one hand, this is required for stuff like firefox that can only run once per user. On the other hand, it seems rather natural to share contexts between multiple logins of the same user. The same 'user' cannot sit in front of two machines at the same time, so why allow two independent logins? Anyhow, there's a lot going on right now and it'll take some time until this is all implemented. But so far, there haven't been any use-cases that cannot be solved with per-user systemd. Sure a same 'user' can't sit in front of two machines, but that don't stop me open two sessions on two machines. By using per-user systemd instance, it's very hard, if not impossible, to manage multiple sessions of a single user. Does this mean systemd is banning multiple sessions for single user? A bigger problem is that polkit depends on sessions to authentication actions. And since the per-user systemd instance won't normally belong to an active session, it's impossible for applications started by per-user systemd instance to, say, mount an USB stick. Thanks David Regards, Yuxuan Shui ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per session systemd?
Hi, After reading some more mails and thinking about it a bit more, I seems to have a better understanding. I know that a per-user systemd is used to start service which should only be started once for every user. But I also want systemd to be able to start applications for every session (e.g. window manager), which is hard to do with the currect systemd --user implementation. I think there're two solutions here. 1) A per-session systemd instance. That's possibly the most simple solution. The changes needed is adding a 'User=' property to session unit, and give the change the ownership of the session cgroup to the given user. Then the user could start systemd after he start X (e.g. put systemd into .xinitrc). Also systemd probably have to read configuration files from a different position as the systemd --user (e.g. $XDG_CONFIG_HOME/systemd/session). One advantage of this solutions is that systemd will automatically have all the environment variables set up during the X startup sequence. 2) Let the per-user systemd start service in session. I think this is what David meant. I don't know what changes are needed in systemd to do this. Since the session cgroup is owned by root, maybe the ownership should be changed to the user? Or a new systemd API to start service in a given session? I don't know. Also it seems to be hard to maintain different sets of environment variables needed to start applications in different sessions. Correct me if I'm wrong. Regards, Yuxuan Shui. On Mon, Mar 3, 2014 at 4:46 PM, Yuxuan Shui yshu...@gmail.com wrote: Hi, On Mon, Mar 3, 2014 at 4:11 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Mon, Mar 3, 2014 at 8:30 AM, Yuxuan Shui yshu...@gmail.com wrote: Hi, This mail might be a little bit later for the topic, but I would like to share my thoughts anyway. Before systemd 206 was released, there are a few users (I don't know how many of them are there, but there's a page about it on archlinux's wiki. So I guess it's a well-known use case.) who use systemd to manage their sessions. For example, they will exec systemd in their ~/.xinitrc, and have systemd start all their X applications. systemd --user ist started by PAM for any proper user login. So you could fix that by just using a proper login manager (if you don't want the big ones, there's small stuff like 'slim', too). Even if you don't want these, I still recommend to do a PAM authentication in your startup script. This might even be via pam_rootok so you don't have to enter any password. Yea, I know that. The problem is this instance is started once per every user. And this systemd instance don't belong to the same session as the logged-in user, causing problems I described below. I know this kind of use case has never been explicitly supported by systemd, but it was a really nice _accidental_ feature. However, after the cgroup changes made in the systemd 206 release, it became impossible to use systemd in such way. I saw some user complaints, but the systemd developers seemed unmoved. Maybe because the original purpose of systemd --user is to start per-user systemd instances. There're hacks to make systemd usable under a X session. But that's very complicated, and contains many pitfalls (User have to set a lot of environmental variables, and this makes logind unhappy since the systemd user instance is not in the same session as X). Besides, there're reasonable use cases which can't be covered by a per-user systemd instance, like periodically starting a graphic application. Why is that not possible with per-user instances? Yes, it's possible, but it has many pitfalls as I described. Here I mean if you *don't use those hacks*, you can't do things like periodically starting a graphic application So, I wrote a very dirty hack for my systemd, and have been using it till today. I add a 'User=' property to a session, and have systemd chown the cgroup to the given user, so I can start systemd in my .xinitrc as I used to. I admit this is probably a very bad hack, and I'm not sure if it will still work after the soon coming cgroup rework. That's why I'm writing this mail. I want to point out the reason behind use systemd as a session manager, so you will probably understand why I want to do this and help me. Since I can't get this done by myself with my limited systemd knowledge. Any help will be appreciated. It will be better if you can convince me that I'm stupid and this feature is totally useless. What's the problem with per-user systemd besides startup synchronization? (which is fixed by pam..) Our concept basically boils down to treating sessions as a banal ref-count to a user. Instead of putting all the big stuff into a session, we now move it to the user. You can still have multiple sessions, but they share the bulk of data now. On the one hand, this is required for stuff like
Re: [systemd-devel] Per session systemd?
Hi On Mon, Mar 3, 2014 at 12:16 PM, Yuxuan Shui yshu...@gmail.com wrote: Hi, After reading some more mails and thinking about it a bit more, I seems to have a better understanding. I know that a per-user systemd is used to start service which should only be started once for every user. But I also want systemd to be able to start applications for every session (e.g. window manager), which is hard to do with the currect systemd --user implementation. The idea is to run your window-manager only once per user. If you want multiple logins with the same window-manager, then your window manager should support that, not systemd. You wm daemon should simply be able to serve multiple sessions from one instance. Thanks David I think there're two solutions here. 1) A per-session systemd instance. That's possibly the most simple solution. The changes needed is adding a 'User=' property to session unit, and give the change the ownership of the session cgroup to the given user. Then the user could start systemd after he start X (e.g. put systemd into .xinitrc). Also systemd probably have to read configuration files from a different position as the systemd --user (e.g. $XDG_CONFIG_HOME/systemd/session). One advantage of this solutions is that systemd will automatically have all the environment variables set up during the X startup sequence. 2) Let the per-user systemd start service in session. I think this is what David meant. I don't know what changes are needed in systemd to do this. Since the session cgroup is owned by root, maybe the ownership should be changed to the user? Or a new systemd API to start service in a given session? I don't know. Also it seems to be hard to maintain different sets of environment variables needed to start applications in different sessions. Correct me if I'm wrong. Regards, Yuxuan Shui. On Mon, Mar 3, 2014 at 4:46 PM, Yuxuan Shui yshu...@gmail.com wrote: Hi, On Mon, Mar 3, 2014 at 4:11 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Mon, Mar 3, 2014 at 8:30 AM, Yuxuan Shui yshu...@gmail.com wrote: Hi, This mail might be a little bit later for the topic, but I would like to share my thoughts anyway. Before systemd 206 was released, there are a few users (I don't know how many of them are there, but there's a page about it on archlinux's wiki. So I guess it's a well-known use case.) who use systemd to manage their sessions. For example, they will exec systemd in their ~/.xinitrc, and have systemd start all their X applications. systemd --user ist started by PAM for any proper user login. So you could fix that by just using a proper login manager (if you don't want the big ones, there's small stuff like 'slim', too). Even if you don't want these, I still recommend to do a PAM authentication in your startup script. This might even be via pam_rootok so you don't have to enter any password. Yea, I know that. The problem is this instance is started once per every user. And this systemd instance don't belong to the same session as the logged-in user, causing problems I described below. I know this kind of use case has never been explicitly supported by systemd, but it was a really nice _accidental_ feature. However, after the cgroup changes made in the systemd 206 release, it became impossible to use systemd in such way. I saw some user complaints, but the systemd developers seemed unmoved. Maybe because the original purpose of systemd --user is to start per-user systemd instances. There're hacks to make systemd usable under a X session. But that's very complicated, and contains many pitfalls (User have to set a lot of environmental variables, and this makes logind unhappy since the systemd user instance is not in the same session as X). Besides, there're reasonable use cases which can't be covered by a per-user systemd instance, like periodically starting a graphic application. Why is that not possible with per-user instances? Yes, it's possible, but it has many pitfalls as I described. Here I mean if you don't use those hacks, you can't do things like periodically starting a graphic application So, I wrote a very dirty hack for my systemd, and have been using it till today. I add a 'User=' property to a session, and have systemd chown the cgroup to the given user, so I can start systemd in my .xinitrc as I used to. I admit this is probably a very bad hack, and I'm not sure if it will still work after the soon coming cgroup rework. That's why I'm writing this mail. I want to point out the reason behind use systemd as a session manager, so you will probably understand why I want to do this and help me. Since I can't get this done by myself with my limited systemd knowledge. Any help will be appreciated. It will be better if you can convince me that I'm stupid and this feature is totally useless. What's the problem with per-user
Re: [systemd-devel] Per session systemd?
On Mon, 03.03.14 15:30, Yuxuan Shui (yshu...@gmail.com) wrote: Heya, That's why I'm writing this mail. I want to point out the reason behind use systemd as a session manager, so you will probably understand why I want to do this and help me. Since I can't get this done by myself with my limited systemd knowledge. You should be able to place your WM in a systemd user service. Then, when you log in, do something like this: systemctl import-environment DISPLAY XAUTHORITY systemctl start my-wm.service The first command will upload the $DISPLAY variable into the systemd user instance. The second instance will then spawn the WM. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per session systemd?
On Mon, 03.03.14 19:16, Yuxuan Shui (yshu...@gmail.com) wrote: Hi, After reading some more mails and thinking about it a bit more, I seems to have a better understanding. I know that a per-user systemd is used to start service which should only be started once for every user. But I also want systemd to be able to start applications for every session (e.g. window manager), which is hard to do with the currect systemd --user implementation. I think there're two solutions here. 1) A per-session systemd instance. That's possibly the most simple solution. The changes needed is adding a 'User=' property to session unit, and give the change the ownership of the session cgroup to the given user. Then the user could start systemd after he start X (e.g. put systemd into .xinitrc). Also systemd probably have to read configuration files from a different position as the systemd --user (e.g. $XDG_CONFIG_HOME/systemd/session). We want to move from a per-session to a per-user scheme to simplify things, not making it moer complicated... One advantage of this solutions is that systemd will automatically have all the environment variables set up during the X startup sequence. 2) Let the per-user systemd start service in session. I think this is what David meant. I don't know what changes are needed in systemd to do this. Since the session cgroup is owned by root, maybe the ownership should be changed to the user? Or a new systemd API to start service in a given session? In the long run the idea is that a desktop compositor/WM will be a singleton that manages the devices of all local sessions you might have created, and merges them into a single virtual huge workplace. If you log into two seats they will thus magically merge into one big workplace. Each time you log into a seat you can more real estate added to your existing compositor. In the short term the compositors can't do this just yet, so the idea is that the first time you login we start the compositor/WM on that screen. And if you login a second time on another seat you will get a simply dialog that gives you two options: Disconnect other session and Disconnect this session. And a third option is to just work-around our ideas by making your WM a templated service: my-wm@.service: [Service] Environment=DISPLAY=%I ExecStart=/usr/bin/my-wm And then when you log in run systemctl start my-wm@$DISPLAY.service and you get it loaded. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Per session systemd?
Hi, This mail might be a little bit later for the topic, but I would like to share my thoughts anyway. Before systemd 206 was released, there are a few users (I don't know how many of them are there, but there's a page about it on archlinux's wiki. So I guess it's a well-known use case.) who use systemd to manage their sessions. For example, they will exec systemd in their ~/.xinitrc, and have systemd start all their X applications. I know this kind of use case has never been explicitly supported by systemd, but it was a really nice _accidental_ feature. However, after the cgroup changes made in the systemd 206 release, it became impossible to use systemd in such way. I saw some user complaints, but the systemd developers seemed unmoved. Maybe because the original purpose of systemd --user is to start per-user systemd instances. There're hacks to make systemd usable under a X session. But that's very complicated, and contains many pitfalls (User have to set a lot of environmental variables, and this makes logind unhappy since the systemd user instance is not in the same session as X). Besides, there're reasonable use cases which can't be covered by a per-user systemd instance, like periodically starting a graphic application. So, I wrote a very dirty hack for my systemd, and have been using it till today. I add a 'User=' property to a session, and have systemd chown the cgroup to the given user, so I can start systemd in my .xinitrc as I used to. I admit this is probably a very bad hack, and I'm not sure if it will still work after the soon coming cgroup rework. That's why I'm writing this mail. I want to point out the reason behind use systemd as a session manager, so you will probably understand why I want to do this and help me. Since I can't get this done by myself with my limited systemd knowledge. Any help will be appreciated. It will be better if you can convince me that I'm stupid and this feature is totally useless. Regards, Yuxuan Shui. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
