2013/2/20 Simon McVittie <[email protected]>: > On 19/02/13 23:55, Peeters Simon wrote: >> or just use a systemd generater to generate systemd .service files from the >> dbus service files. >> (i have something like this laying around slightly unfinished if you >> want code, let me know) > > That would be an interesting way to avoid having to either patch every > single D-Bus session service (there are rather a lot of them!) to have a > systemd unit, or have `dbus-daemon --session` implement the same > display-tracking as `systemd --user`. Could you publish this somewhere, > please?
finished it up for you. https://github.com/SimonPe/systemd-dbus-generator >>> 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. >> >> Display property of org.freedesktop.login1.User? > > Indirectly, yes. User.Display is the (ID and) object path of a > login1.Session, and that Session's Display property is the X11 display > we actually wanted. > > In the systemd patches I'm trying out, I'm actually planning to use > libsystemd-login (= inotify on files in /run), because systemd's D-Bus > code is mostly geared towards being a service rather than being a client > of an external service; listening for those signals without a > vulnerability equivalent to CVE-2013-0292 would basically require > reinventing GDBusProxy (track the owner of the o.fd.login1 name, ignore > signals not from that owner), and that's a lot of code for what ought to > be a simple task. > >> My opinion is that gnome-settings-daemon does to many things. > > I'm sure it does; but the more changes get added to the critical path, > the longer it will take to make them all, agree with the various > projects' maintainers that they are the *right* changes, and get them > all landed. > > I do notice that gnome-settings-daemon isn't D-Bus-activatable - it's > currently run as an "application" by gnome-session, which will > presumably remain a one-per-DISPLAY thing - so it might be OK to have > several g-s-d instances queueing for the org.gnome.SettingsDaemon name, > and have each of them additionally take an "instanced" bus name like > org.gnome.SettingsDaemon._3a0 or something? I don't know a lot about g-s-d, but it should be a possible solution. >> we could use a little wrapper binary that tracks the users sessions, and >> launches an instantiated service for each new display, so that all X11 stuff >> (window managers included) runs once per DISPLAY but the other services run >> once per user. > > I'm not at all sure that window managers should be a systemd service. My > understanding is that window managers that aren't part of a larger > "desktop environment" generally act as the main process run by xinit or > gdm or whatever, whose lifetime defines the lifetime of the X session? > (So, the same role as gnome-session.) maybe, but this would create a split between the window manager and the rest of the session. It would also mean that one can not use systemd features like Restart=always and maybe even the systemd's watchdog system, to simplify there failover policy. Having the window managers as services also allows us to use a system similar to the display-manger.service, and to switch window managers while keeping the session. (systemctl --user stop i3.service && systemctl --user start gnome-shell.service) >> i3.service: >> [Service] >> ExecStart=/usr/libexec/systemd-foreach-display --user [email protected] > > This seems to assume that you always have one or more displays? Unless > systemd-foreach-display is actually a daemon... the systemd-foreach-display would be a daemon monitoring the logind sessions, starting new instances when new graphical sessions appear, and stopping instances when there session disappears. (note that this is still purely hypothetical) >> The only thing blocking this for now is that systemd does not appear >> to send PropertyChanged signals for this property. > > This can currently be worked around by monitoring PropertyChanged for > Sessions, I think - the Display can't change unless either there is a > new login session with an X display, or an existing login session with > an X display has gone away. I might even have some time during next week to see if i can write something like this. > > S the other S _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
