On Sun, 01.12.13 21:25, Hristo Venev ([email protected]) wrote: > I've implemented session mode for systemd. I am currently using it and it > works > pretty okay. I just had to generate D-Bus user services for D-Bus activation > to > work. > > A new variable, XDG_SESSION_DIR, has been added. It defaults to > /run/session/$XDG_SESSION_ID and is to be used for session-specific files as > it > is `rm -rf`-ed on logout. There, in ./systemd/private, the systemd socket is > stored. Also, my implementation of session units stores the D-Bus socket in > ./dbus/session_bus_socket. > > Sorry if I am sending this for the third time but I can't see it in the > mailing > list.
Hmm, so, as Kay already mentioned, it was actually an explicit decision not to support a session mode in systemd, or a per-session runtime dir. Having system + user + session instances of systemd certainly sounds like overkill, and we should actually encourage sharing of data between sessions of the same user, so that he for example gets access to an existing session's keyring when also logging in via ssh. Moreover more apps than not actually do not support running multiple times by same same user in multiple sessions. A few (like firefox) explicitly block against that with a lock file, but in most cases this is just something that isn't tested and hence a game of luck. So, in order to keep things simply we are trying to push things towards a per-user bus, a per-user systemd instance and a per-user runtime dir. Then, for things where it's worth it programs can include the session identifier in whatever resource they need on their own. For example, if an application really wants to be compatible with running multiple times from different sessions by the same user, then it can include XDG_SESSION_ID in the bus name it grabs, in the files it creates in XDG_RUNTIME_DIR and so on. The net result of that is probably that while users can easily have multiple text logins at the same time, there's going to be only one graphical session. I hope this makes some sense, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
