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? >> 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? > 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.) > i3.service: > [Service] > ExecStart=/usr/libexec/systemd-foreach-display --user i3@.service This seems to assume that you always have one or more displays? Unless systemd-foreach-display is actually a daemon... > 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. S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel