<div dir="ltr">Hi,<div><br></div><div>After reading some more mails and thinking about it a bit more, I seems to have a better understanding.</div><div><br></div><div>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.</div>

<div><br></div><div>I think there're two solutions here.</div><div><br></div><div>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).</div>

<div><br></div><div>One advantage of this solutions is that systemd will automatically have all the environment variables set up during the X startup sequence.</div><div><br></div><div>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? </div>

<div><br></div><div>I don't know. Also it seems to be hard to maintain different sets of environment variables needed to start applications in different sessions.</div><div><br></div><div>Correct me if I'm wrong.</div>

<div><br></div><div><br></div><div class="gmail_extra"><div><div dir="ltr">Regards,<div>Yuxuan Shui.</div></div></div>
<br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 4:46 PM, Yuxuan Shui <span dir="ltr"><<a href="mailto:yshuiv7@gmail.com" target="_blank">yshuiv7@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Hi,<div class=""><div><br>On Mon, Mar 3, 2014 at 4:11 PM, David Herrmann <<a href="mailto:dh.herrmann@gmail.com" target="_blank">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" target="_blank">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><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 class="">
<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><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><div class="h5">
<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></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>
</blockquote></div><br></div></div>