Bug#986166: systemd: 'systemd --user' not functional. Regardless of user, org.freedesktop.systemd1 exits with status 1

[Michael Biebl]

Am 30.03.2021 um 20:14 schrieb Troy Telford:
> Package: systemd
> Version: 247.3-3
> Severity: normal
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> This was probably due to an apt update/upgrade. I haven't been configuring my
> system, but about two weeks ago, "systemd --user" stopped working entirely -
> none of the user units start up upon user login. The first thing I noticed is
> no sound, but it didn't take long to find that systemd wasn't running any user
> units.
>
> * What exactly did you do (or not do) that was effective (or ineffective)?
>
> Initially, I found that XDG_RUNTIME_DIR wasn't being set anymore -- so I added
> `export XDG_RUNTIME_DIR=/run/user/$(id -u)` to my .xsessionrc. It didn't fix
> the issue for login, but I could at least run `systemd --user` and start up the
> processes after login. However, even that is broken now: I invariably get
> "Process org.freedesktop.systemd1 exited with status 1"
>
> /var/log/daemon.log has a corresponding message from DBUS about
> org.freedesktop.systemd1 being activated, but dying:
> Mar 30 12:08:01 pilot.pariahzero.net dbus-daemon[2025881]: [session uid=1000
> pid=2025879] Activating service name='org.freedesktop.systemd1' requested by
> ':1.155' (uid=1000 pid=2433850 comm="systemctl --user --failed ")
> Mar 30 12:08:01 pilot.pariahzero.net dbus-daemon[2025881]: [session uid=1000
> pid=2025879] Activated service 'org.freedesktop.systemd1' failed: Process
> org.freedesktop.systemd1 exited with status 1
>
> The problem happens for all users on the system.
>
> I'll see if I can get more verbose logging to give any additional details about
> why org.freedesktop.systemd1 is exiting. If you know offhand, I'd definitely
> give it a try.
>

What's the output of
apt-cache policy dbus-user-session
apt-cache policy dbus-x11

[Troy Telford]

> On Mar 30, 2021, at 12:22 PM, Michael Biebl <bi...@debian.org> wrote:
>
> What's the output of
> apt-cache policy dbus-user-session
> apt-cache policy dbus-x11

# apt-cache policy dbus-user-session

dbus-user-session:
Installed: 1.12.20-2
Candidate: 1.12.20-2
Version table:
1.13.18-2 1
1 http://ftp.debian.org/debian experimental/main amd64 Packages
*** 1.12.20-2 500
500 http://ftp.us.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

# apt-cache policy dbus-x11
dbus-x11:
Installed: 1.12.20-2
Candidate: 1.12.20-2
Version table:
1.13.18-2 1
1 http://ftp.debian.org/debian experimental/main amd64 Packages
*** 1.12.20-2 500
500 http://ftp.us.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

[Troy Telford]

Detail is provided to avoid https://xkcd.com/979/ from happening to anybody in the future.

After a chat on IRC, we tested our a few scenarios, and found that _local_ users worked fine. The users that didn’t work were the LDAP users, which wouldn’t load systemd-user.

I tried adding the one-shot at https://src.fedoraproject.org/rpms/nss_nis/blob/rawhide/f/nss_nis.conf to try a different restriction for the NSS service and systemd-user would work, however other things broke.

We eventually determined that the end problem wasn’t systemd-user, but rather the local LDAP configuration, which is _old_, and uses services that probably should be replaced with sssd.

That’s exactly what I did, and now sssd gets the users properly, and systemd-user starts with no problems.

Of note is https://github.com/systemd/systemd/blob/v248/NEWS, which has a warning that:

NOTE: This has a chance of breaking nss-ldap and similar NSS modules
that embed a network facing module into any process using getpwuid()
or related cal

Which is exactly what happened.

This issue can be closed.

> On Mar 30, 2021, at 12:22 PM, Michael Biebl <bi...@debian.org> wrote:
>