[systemd-devel] Per session systemd?

[Yuxuan Shui]

Hi,

On Mon, Mar 3, 2014 at 4:11 PM, David Herrmann <dh.herrmann at gmail.com>
wrote:
> Hi
>
> On Mon, Mar 3, 2014 at 8:30 AM, Yuxuan Shui <yshuiv7 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140303/fdda4a78/attachment.html>