<div dir="ltr">Hi,<div><br>On Mon, Mar 3, 2014 at 4:11 PM, David Herrmann <<a href="mailto:dh.herrmann@gmail.com">dh.herrmann@gmail.com</a>> wrote:<br>> Hi<br>><br>> On Mon, Mar 3, 2014 at 8:30 AM, Yuxuan Shui <<a href="mailto:yshuiv7@gmail.com">yshuiv7@gmail.com</a>> wrote:<br>
>> Hi,<br>>><br>>> This mail might be a little bit later for the topic, but I would like<br>>> to share my thoughts anyway.<br>>><br>>> Before systemd 206 was released, there are a few users (I don't know<br>
>> how many of them are there, but there's a page about it on archlinux's<br>>> wiki. So I guess it's a well-known use case.) who use systemd to<br>>> manage their sessions. For example, they will exec systemd in their<br>
>> ~/.xinitrc, and have systemd start all their X applications.<br>><br>> systemd --user ist started by PAM for any proper user login. So you<br>> could fix that by just using a proper login manager (if you don't want<br>
> the big ones, there's small stuff like 'slim', too). Even if you don't<br>> want these, I still recommend to do a PAM authentication in your<br>> startup script. This might even be via pam_rootok so you don't have to<br>
> enter any password.</div><div>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.</div>
<div><br>><br>>> I know this kind of use case has never been explicitly supported by<br>>> systemd, but it was a really nice _accidental_ feature. However, after<br>>> the cgroup changes made in the systemd 206 release, it became<br>
>> impossible to use systemd in such way.<br>>><br>>> I saw some user complaints, but the systemd developers seemed unmoved.<br>>> Maybe because the original purpose of systemd --user is to start<br>
>> per-user systemd instances. There're hacks to make systemd usable<br>>> under a X session. But that's very complicated, and contains many<br>>> pitfalls (User have to set a lot of environmental variables, and this<br>
>> makes logind unhappy since the systemd user instance is not in the<br>>> same session as X). Besides, there're reasonable use cases which can't<br>>> be covered by a per-user systemd instance, like periodically starting<br>
>> a graphic application.<br>><br>> Why is that not possible with per-user instances?</div><div>Yes, it's possible, but it has many pitfalls as I described.</div><div><br></div><div>Here I mean if you <i>don't use those hacks</i>, you can't do things like periodically starting a graphic application</div>
<div>><br>>> So, I wrote a very dirty hack for my systemd, and have been using it<br>>> till today. I add a 'User=' property to a session, and have systemd<br>>> chown the cgroup to the given user, so I can start systemd in my<br>
>> .xinitrc as I used to. I admit this is probably a very bad hack, and<br>>> I'm not sure if it will still work after the soon coming cgroup<br>>> rework.<br>>><br>>> That's why I'm writing this mail. I want to point out the reason<br>
>> behind use systemd as a session manager, so you will probably<br>>> understand why I want to do this and help me. Since I can't get this<br>>> done by myself with my limited systemd knowledge.<br>
>><br>>> Any help will be appreciated. It will be better if you can convince me<br>>> that I'm stupid and this feature is totally useless.<br>><br>> What's the problem with per-user systemd besides startup<br>
> synchronization? (which is fixed by pam..)<br>><br>> Our concept basically boils down to treating sessions as a banal<br>> ref-count to a user. Instead of putting all the big stuff into a<br>> session, we now move it to the user. You can still have multiple<br>
> sessions, but they share the bulk of data now. On the one hand, this<br>> is required for stuff like firefox that can only run once per user. On<br>> the other hand, it seems rather natural to share contexts between<br>
> multiple logins of the same user. The same 'user' cannot sit in front<br>> of two machines at the same time, so why allow two independent logins?<br>> Anyhow, there's a lot going on right now and it'll take some time<br>
> until this is all implemented. But so far, there haven't been any<br>> use-cases that cannot be solved with per-user systemd.</div><div>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?</div>
<div><br></div><div>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.</div>
<div><br>><br>> Thanks<br>> David<br><br></div><div>Regards,</div><div>Yuxuan Shui</div></div>