[systemd-devel] Per session systemd?

[Yuxuan Shui]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140303/c348b94b/attachment.html>