GNOME Bugzilla – Bug 690866
Integrate better with systemd
Last modified: 2017-11-23 09:28:46 UTC
Created attachment 232378 [details] [review] Add GNOME dummy session Currently, gnome-session doesn't support sessions with no Required Components. Someone could only want a gnome-session running for its DBus API, while managing his session with something else, like "systemd --user". This patches allow to start a dummy gnome-session which does not start anything but the autostart software and the DBus API with gnome-session --session=gnome-dummy Another solution would be to externalize the DBus API to another binary which would always be started by gnome-session.
hmm, so gnome-session is still running autostart services under this scenario, right? One idea might be a systemd generator that automatically translates xdg autostart files to systemd services at runtime. That way systemd truely runs the show here.
(retitling for the apparent more general goal here)
It's still running autostart services unless you pass it '-a /dev/null' which I do in my systemd user service. For now on I converted by hand the autostart services which interrested me, but I think a convertor would indeed by appreciated. It would not have anything to do with gnome-session, but rather systemd though.
Lennart, what do you think? Would it make sense to put such a generator in the systemd tree? The gnome-session tree? Or is it even a good idea?
I think writing a generator for this would make a ton of sense. And we probably should ship that in systemd, as .desktop files are kinda standardized and people might want to share that with KDE, too.
Marc-Antoine, do you have service files for the "required" components? I'm thinking gnome-settings-daemon, and gnome-shell. It would be interesting to make this testable at least, so any instructions on how to set it up would be useful.
I wrote a post about how I did it there : http://www.imagination-land.org/posts/2013-01-01-systemd-as-a-session-manager.html My unit files are available there: https://github.com/Keruspe/system-config/tree/master/systemd/user There are services for gnome-session, gnome-shell, gnome-settings-daemon and others (most of them taken and adapted from other repositories, as I said in the post)
Review of attachment 232378 [details] [review]: I'm not convinced we want to ship the 'dummy' session with gnome-session, necessarily. But we should take the part that makes an empty session not an error. Can you provide a separate patch for that ?
Created attachment 234184 [details] [review] support empty session
Created attachment 234185 [details] [review] provide a dummy session
Review of attachment 234184 [details] [review]: This looks fine to me
Comment on attachment 234185 [details] [review] provide a dummy session Attachment 234185 [details] pushed as 4c7e1c8 - provide a dummy session
(In reply to comment #5) > I think writing a generator for this would make a ton of sense Does this still apply if systemd shares a single D-Bus session and `systemd --user` between multiple login sessions, potentially including more than one X11 display? (Would the generated units be instanced by X11 display?) Feedback on the thread starting at <http://lists.freedesktop.org/archives/systemd-devel/2013-February/009119.html> would be very much appreciated.
Any progress on this? Is still of interest to create the systemd generator?
The better approach is to make services dbus activatable, which gives us integration with systemd for "free". Still, some services won't be dbus activatable, so having the generator makes sense. There was some discussion about this recently on bug 757571 (I'm out for a few weeks, though)
Reviving this and CC:ing Martin. Martin attempted to implement this in Ubuntu for the Unity desktop: https://www.youtube.com/watch?v=hq18daxTkLA Would you have a list of the systemd blockers? Would be great if you had a textual version of the video (maybe a mail you sent) so we can start spinning this bug into separate tasks.
Sorry for the terribly late answer! The "textual version" and list of potential improvements are more or less encoded in the current startup script [1] and top-level gnome-session.service [2]. As you can see, the .service is more or less fine (the noise in there should be mostly obsolete, and the upstart bits don't apply to upstream anyway), but the startup script (the bit that goes into the /usr/share/xsessions/*.desktop file's Exec= line) is quite verbose. Back then I thought https://github.com/systemd/systemd/issues/3750 would be a helpful improvement to get rid of the worst/biggest hack in there.; it would still be, but as it's non-trivial to implement and still outstanding, I figure adding some extra After=graphical-session-pre.target to all graphical session services is the path of least resistance here. So with that, I don't think there are any blockers on the systemd side. [1] http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/view/head:/debian/data/run-systemd-session [2] http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/view/head:/debian/data/gnome-session.service
I should have some time to work on this this cycle. We talked about it a bit at GUADEC (time flies!) - Bastien/Cosimo, would you be able to remind me what you thought the gnome-session task was please? In the meantime I think that we could probably already start shipping units for g-s-d/gnome-shell.
there's patches to add systemd services for g-s-d on bug 741688. gnome-shell will need to be fixed to find the active logind session instead of assuming it's started in it.
(In reply to Ray Strode [halfline] from comment #19) > there's patches to add systemd services for g-s-d on bug 741688. Right, yeah, let's use that bug to discuss the g-s-d part. > gnome-shell will need to be fixed to find the active logind session instead > of assuming it's started in it. As Bastien said in comment #16, we should probably create separate bugs for the work required and make them block/depend/the correct bz term on this one, which can be the master bug. Thanks for the pointers!