I need to run such services only after the graphical session and not with default.target, because these programs may have some constraints like being a graphical program (thus needing an X display to start) or needing SSH access to a machine (thus needing my SSH passphrase unlocked by GNOME keyring), etc.
But, this doesn’t work anymore with GNOME 40.
I also tried with other settings (gnome-session.target instead of graphical-session.target, Requires=, BindsTo=, etc etc ) but it didn’t work either.
It seems there was a big change in the session management in GNOME 40, because when I list user services with systemd --user status, I only see a bunch of services and the apps I started manually during the session, but not the usual GNOME services (like the various settings daemon modules for example) nor the apps started automatically from XDG autostart desktop files; all those are now in another CGroup (session-X.scope) instead of the usual user@UID.service CGroup.
So, what is the new correct way to start a systemd user service with GNOME 40 ?
That should work for all systemd using desktop environment. But using WantedBy=graphical-session.target still requires enabling the service either per-user or system-wide.
i.e. did you also run systemctl --user enable YOUR.service or systemctl --global enable YOUR.service?
That said, not seeing org.gnome.SettingsDaemon.*.service, etc. sounds like you are hitting the fallback. Said differently, your systemd configuration is probably broken making it impossible to start the main GNOME session systemd target. This in turn causes gnome-session-binary to do an auotmatic fallback to legacy login (which btw. always happens for the GDM screen currently).
What you should do is simply have a look at journalctl --user for the time when your sessions tarts. You should see a message about the fallback from gnome-session-binary (or similar), and before that there are probably some log messages from systemd telling you why things are falling apart.
On a machine with GNOME 3.3x (where my systemd user services do work as expected), I do indeed see these messages from gnome-session-binary about falling back :
janv. 24 09:54:41 solaris gnome-session[4346]: gnome-session-binary[4346]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
janv. 24 09:54:41 solaris gnome-session-binary[4346]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
janv. 24 09:54:41 solaris gnome-session[4346]: gnome-session-binary[4346]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
janv. 24 09:54:41 solaris gnome-session-binary[4346]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
janv. 24 09:54:41 solaris gnome-session[4346]: gnome-session-binary[4346]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
janv. 24 09:54:41 solaris gnome-session-binary[4346]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
On the machine with GNOME 40 (where my systemd user services don’t work), I don’t see anything about falling back, but I see a similar error though :
janv. 24 19:07:46 arche gnome-session[5328]: gnome-session-binary[5328]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
janv. 24 19:07:46 arche gnome-session-binary[5328]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Both use GDM, the only difference is that the one with GNOME 3.3x has WaylandEnable=false (so even the GDM login prompt uses Xorg) and the one with GNOME 40 doesn’t have this line (so the GDM login prompt is using Wayland) but the user session is started as an Xorg session.
Could it be the cause ? Also, what did you mean by “which btw. always happens for the GDM screen currently” ?
Both logs must be messages from the GDM user. Please have a look at journalctl --user --since "5 min ago" or similar from within your own session that you just logged into.
The only difference is that the fallback warning is now hidden in GDM.
What distribution? Can you check the parameters that your running gnome-session-binary got when logging in?
What you can do:
Just paste the logs, maybe you overlooked something relevant
Modify /usr/bin/gnome-session to pass --debug to gnome-session-binary for more debug output
At the end of the day, I don’t really have enough information right now to say more. It still sounds like you are getting a non-systemd login, but there are only two ways of that happening:
--builtin is explicitly passed to gnome-session-binary (or, the distribution patches it and requires --systemd to be passed).
The systemd target can’t be activated and gnome-session-binary falls back.
I’m on Debian Unstable, with GNOME 40. According to ps fax, /usr/libexec/gnome-session-binary is run without any argument.
Per your suggestion, I tried to modify /usr/bin/gnome-session to add --debug to the /usr/libexec/gnome-session-binary call, and it did output a lot more things, but nothing I found relevant, except maybe :
janv. 26 22:05:57 arche /usr/libexec/gdm-x-session[5903]: gnome-session-binary[5903]: DEBUG(+): Using systemd for session tracking
Which shows that systemd is indeed managing the session, but still nothing about falling back.
I’m hesitant to paste the whole log online for privacy reasons, but if you agree, I could send it to you.
Today I upgraded this Debian Unstable box and there was an upgrade for gnome-session (dated yesterday, January 29th 2022). Changelog says :
Configure with systemd_session=default on Linux.
On Linux systems that have dbus-user-session, we now prefer systemd
mode, as we did in bullseye (until it was accidentally disabled in
40.1.1-2)
So you did correctly pinpoint the origin if the problem, and it was indeed a bug in the packaging.
40.1.1-2 was released on October 11th, 2021, so I guess every Debian Unstable user was affected since that date, and wouldn’t even know unless tinkering with custom user services, or reading the output of systemctl --user status and wondering where all the GNOME services went.
Now everything seems back in order, systemctl --user status correctly shows app.slice and session.slice, with all the GNOME services, and my custom user services correctly start after graphical-session.target (or gnome-session.target for GNOME-sepcific ones) is reached.
Thanks again for your help, and sorry for the noise
