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