After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 690866 - Integrate better with systemd
Integrate better with systemd
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: gnome-session
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on: 741688
Blocks:
 
 
Reported: 2012-12-29 19:18 UTC by Marc-Antoine Perennou
Modified: 2021-06-14 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add GNOME dummy session (2.57 KB, patch)
2012-12-29 19:18 UTC, Marc-Antoine Perennou
needs-work Details | Review
support empty session (1.20 KB, patch)
2013-01-23 13:12 UTC, Marc-Antoine Perennou
accepted-commit_now Details | Review
provide a dummy session (1.85 KB, patch)
2013-01-23 13:12 UTC, Marc-Antoine Perennou
committed Details | Review

Description Marc-Antoine Perennou 2012-12-29 19:18: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.
Comment 1 Ray Strode [halfline] 2013-01-03 21:52:23 UTC
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.
Comment 2 Ray Strode [halfline] 2013-01-03 21:53:12 UTC
(retitling for the apparent more general goal here)
Comment 3 Marc-Antoine Perennou 2013-01-04 09:09:45 UTC
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.
Comment 4 Ray Strode [halfline] 2013-01-07 16:03:14 UTC
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?
Comment 5 Lennart Poettering 2013-01-07 16:04:43 UTC
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.
Comment 6 Bastien Nocera 2013-01-13 17:39:11 UTC
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.
Comment 7 Marc-Antoine Perennou 2013-01-13 17:42:36 UTC
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)
Comment 8 Matthias Clasen 2013-01-23 13:08:39 UTC
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 ?
Comment 9 Marc-Antoine Perennou 2013-01-23 13:12:27 UTC
Created attachment 234184 [details] [review]
support empty session
Comment 10 Marc-Antoine Perennou 2013-01-23 13:12:57 UTC
Created attachment 234185 [details] [review]
provide a dummy session
Comment 11 Matthias Clasen 2013-01-24 00:00:08 UTC
Review of attachment 234184 [details] [review]:

This looks fine to me
Comment 12 Ray Strode [halfline] 2013-02-19 18:36:42 UTC
Comment on attachment 234185 [details] [review]
provide a dummy session

Attachment 234185 [details] pushed as 4c7e1c8 - provide a dummy session
Comment 13 Simon McVittie 2013-02-22 18:44:38 UTC
(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.
Comment 14 Javier Jardón (IRC: jjardon) 2015-11-27 13:05:32 UTC
Any progress on this? Is still of interest to create the systemd generator?
Comment 15 Ray Strode [halfline] 2015-11-28 00:00:44 UTC
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)
Comment 16 Bastien Nocera 2017-05-30 10:18:33 UTC
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.
Comment 17 Martin Pitt 2017-11-14 21:29:39 UTC
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
Comment 18 Iain Lane 2017-11-22 11:51:14 UTC
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.
Comment 19 Ray Strode [halfline] 2017-11-22 19:28:14 UTC
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.
Comment 20 Iain Lane 2017-11-23 09:28:18 UTC
(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!
Comment 21 Iain Lane 2018-01-17 18:13:14 UTC
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
Comment 22 Bastien Nocera 2018-01-25 10:33:57 UTC
Please don't reassign bugs, thanks.
Comment 23 Bastien Nocera 2018-01-25 10:59:41 UTC
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.
Comment 24 André Klapper 2021-06-14 18:21:01 UTC
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.