GNOME Bugzilla – Bug 696262
gsm_systemd_new() checks for systemd, not for logind
Last modified: 2013-04-04 13:13:44 UTC
gnome-session wants to talk to logind, but actually checks for systemd. It is possible to build systemd without logind, in which case /sys/fs/cgroup/systemd would still exist. For that reason, sd_booted() was recently fixed upstream to only be true if systemd init is active [1] For running systemd init without logind, or for running logind without systemd init we need to change the check to test for logind. For details, see [2] if you are interested. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=66e411811b8090 [2] https://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00092.html
Created attachment 239445 [details] [review] gsm_systemd_new: Check for logind, not for systemd
Created attachment 239456 [details] [review] gsm_systemd_new: Check for logind, not for systemd Sorry, the previous patch was wrong (reversed check).
Created attachment 239462 [details] [review] gsm_systemd_new: Check for logind, not for systemd The previous patch had a confusing changelog. I think this is better.
Review of attachment 239462 [details] [review]: > It is possible to build systemd without logind, in which case sd_booted() would > still succeed. Sure, but it's the opposite you're actually trying to achieve. I doubt that system integrators using systemd would want to use something other than logind for seat tracking.
Ah, we could change the commit message to It is possible to build systemd without logind or run logind without systemd init, in both cases testing for systemd init is wrong. Check for /run/systemd/seats instead, as recommended by systemd upstream. Sounds better?
Review of attachment 239462 [details] [review]: sure
Comment on attachment 239462 [details] [review] gsm_systemd_new: Check for logind, not for systemd Pushed to master with updated changelog. There is no gnome-3-8 branch yet, so I assume this is sufficient for going into 3.8.1.
This broke the gnome-ostree builder; "Drop the now unnecessary linking against libsystemd-daemon." Linking now fails with: /usr/lib/gcc/x86_64-gnomeos-linux/4.7.2/../../../../lib/libsystemd-id128.so: undefined reference to `sd_listen_fds' I suspect this is actually a bug in systemd, but if you don't mind keeping this apparent overlinking for now, I'd appreciate it.
Created attachment 240306 [details] [review] 0001-build-Link-against-libsystemd-daemon-again.patch
Review of attachment 240306 [details] [review]: Eh, no one online now, I'd like to get the gnome-ostree build green again. Will investigate this for real later.
Ah, thanks Colin. Indeed, I was away in the last few days.
> At least some toolchains generate a libsystemd-login.so which doesn't > have a DT_NEEDED on libsystemd-daemon, but it does actually need it. Hm, which symbol in libsystemd-login (or -id128) needs libsystemd-daemon? I don't see any symbol, and neither library links against libsystemd-daemon here?
(In reply to comment #12) > > At least some toolchains generate a libsystemd-login.so which doesn't > > have a DT_NEEDED on libsystemd-daemon, but it does actually need it. > > Hm, which symbol in libsystemd-login (or -id128) needs libsystemd-daemon? I > don't see any symbol, and neither library links against libsystemd-daemon here? This is likely fixed by: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d3b9e0ff4e9f1b0bb328dc57ca5507bac48a6615 But the overlinking here is pretty harmless, so if you don't mind let's keep it in a while?
No, I don't mind at all. I just changed it initially to avoid unnecessary linking, but it doesn't really hurt of course.