GNOME Bugzilla – Bug 690866
Integrate better with systemd
Last modified: 2021-06-14 18:21:01 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!
https://git.gnome.org/browse/gnome-shell/log/?h=wip/laney/systemd-user https://gitlab.gnome.org/iainl/accountsservice https://git.gnome.org/browse/gdm/log/?h=wip/laney/systemd-user https://git.gnome.org/browse/gnome-session/log/?h=wip/laney/systemd-user https://git.gnome.org/browse/gnome-settings-daemon/log/?h=wip/laney/systemd-user My first cut at this, posting here for some initial feedback. There's a bit of sort-of duplication in some of the commits here. When things are started by systemd --user, they aren't in the user's "display" XDG session. So you can't ask systemd what the current process's XDG session is. Instead you can ask logind to find the "display" session, which is what we want. Several of the patches update things to do that. I then added units to gnome-shell, gnome-session and gnome-settings-daemon. Other things with XDG autostart files (gnome-keyring, gnome-software, ...) could be converted once this is working too. Thoughts appreciated. (I haven't actually run this from git - for development I did everything in .config/systemd/user - so sorry if this doesn't work for some stupid reason.) If anyone's at FOSDEM we could maybe talk about next steps there. TODO: - Get GDM session running under --user too - Move environment uploading out of gnome-session - Other minimisation (?) of gnome-session
Please don't reassign bugs, thanks.
Could you please post the patches to bugzilla after this? Use git-bz to upload the patches should make this easier. (In reply to Iain Lane from comment #21) > https://git.gnome.org/browse/gnome-shell/log/?h=wip/laney/systemd-user Looks simple enough. Does this support starting session with both X11 and Wayland? I'm worried about the ordering of the various parts of the desktop as X11 and Wayland startups would have different orderings (eg. g-s-d can start straight away on an X11 session, but needs to wait for gnome-shell and possibly XWayland depending on the plugin) > https://gitlab.gnome.org/iainl/accountsservice No comment from me. > https://git.gnome.org/browse/gdm/log/?h=wip/laney/systemd-user > https://git.gnome.org/browse/gnome-session/log/?h=wip/laney/systemd-user I don't know gdm enough to know why we wouldn't be able to run gdm through a systemd user session. However, I'm not really happy with the code in the shell script. Good enough for a proof-of-concept, but ideally, the "stop units" and "robustness" sections would be written in C, and the subshell section would call an enhanced dbus-update-activation-environment, or a re-written one that'd allow stripping some envvars itself. > https://git.gnome.org/browse/gnome-settings-daemon/log/?h=wip/laney/systemd- > user The first change isn't correct, libcommon links to GTK+, x11, etc. and we really don't need that to link to systemd. Maybe we could instead use GLib/GIO to implement a version that would do the same without linking to systemd? I think it would be best for those plugins that can be run as dbus services to do that, instead of using sd_notify() anyway. I would also expect a meson port to clean up some of the mess in dealing with .desktop/.service files. Hopefully we can script the generation a little. The overall work looks good. I'm however wondering whether we want to support non-systemd sessions (on non-Linux). It'd be a lot of work, and add quite a lot of moving parts, meaning that instead of reducing the amount of work both maintainers and session parts do, we'd end up spending at least twice as much time on it.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.