[systemd-devel] Per session systemd?

[David Herrmann]

Hi

On Mon, Mar 3, 2014 at 12:16 PM, Yuxuan Shui <yshuiv7 at 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 <yshuiv7 at gmail.com> wrote:
>>
>> 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
>
>