On Mon, 18.02.13 20:13, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
> > On 18/02/13 19:08, Kok, Auke-jan H wrote: > > On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie > > <simon.mcvit...@collabora.co.uk> wrote: > >> It looks as though the intention is [...] > >> I have one XDG_RUNTIME_DIR, one 'systemd > >> --user' instance (as per systemd's TODO: started by logind using > >> user@.service, on behalf of pam_systemd) and one 'dbus-daemon --session' > >> instance (presumably started by that 'systemd --user'). > > > > Ideally, we'd have one `systemd --user` survive throughout the entire > > sequence. > > > > I believe that the DBus bits are properly in place to have one single > > user bus per user session. > > To be completely clear: what exactly do you mean by "per user session" > here? Is a "user session" a login1.Session, or a login1.User? > > If I upstream the dbus.service, dbus.socket from user-session-units into > dbus, then we have exactly one `dbus-daemon --session` per `systemd > --user`. If one `systemd --user` spans the whole lifetime of a > login1.User, that's one `dbus-daemon --session` across one or more login > sessions: My original idea would be to have one user dbus.service + dbus.socket for each user session that is run from the user systemd, and invokes dbus-daemon --user. Of course, "dbus-daemon --user" doesn't exist now... (see other mail). > I'm not sure how much that would actually help. GDM and other display > managers currently consider the lifetime of the session to be defined by > the lifetime of a process (which, for GNOME, is gnome-session). In > principle it would be possible to make that process be "start > gnome-session@:0.service on the user systemd, and when it exits, exit", > but I'm not sure that really gains us anything over GDM just running > gnome-session! It seems more useful to get session D-Bus services > systemd-activated, then use those whenever possible (so that systemd > --user can run them on-demand, perhaps starting as soon as the PAM > session opens). My general suggestion is that applications should generally die if their display goes away (libX11 already enforces this...). Having a "gnome-session.service" BTW sounds like a stop-gap though. My intention is to move the service management bit of gnome-session into systemd (or a generator for it), and then move the rest of it into gnome-settings-daemon, and gnome-session would cease to exist, but I am a bit speaking out of my ass here, since I didn't actually look in detail what gnome-session currently consists of in detail. > The next step might be to have a way for XDG applications (.desktop > files) - or at least those that are one-at-a-time-per-user - to be > systemd-activated, so that application launching happens through the > user systemd. Yeah, I would like to see an generator in systemd that converts XDG .desktop files into systemd units. This should probably be a written in GLib, to get the GNOME .desktop file parser into place. Genreally we are a bit careful with glib code in PID 1 (due to OOM), but the nice thing here is that generators are run out-of-process, so this should be fine. > Having a `systemd --user` survive across multiple sessions does conflict > with user-session-units' current assumptions: it would imply that > default.target (or whatever target user@.service runs) cannot usefully > depend on anything that's a GUI. xorg.target would also have to change > (cope with an X11 display being passed in from outside the session, or > be instanced, or something), but that's true for GDM anyway. Not following here.. > No, you're right, it's one per (uid, seat) pair. So for multi-seat > setups there'd certainly have to be some concept of "best X11 display" > (most recently started?) in the environment of new activations. I'd suggest not to support this. In GNOME I would simply not allow multiple local graphical logins of the same user. Instead, the user should get a nice box that he is already logged in elsewhere. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
