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
