[systemd-devel] Per session systemd?

[David Herrmann]

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.

> 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?

> 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.

Thanks
David