Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#61280 - [systemd] 240.0 fails with NIS user login

Attached to Project: Arch Linux
Opened by Heinrich Siebmanns (Harvey) - Saturday, 05 January 2019, 08:14 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 10 December 2019, 13:00 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No


systemd 240.0-2 is not able to login with NIS provided users while 239.370-1 is. On my network machines user logins are provided via NIS and this has been working like a charm until the update to systemd 240.0 landed in testing. Now I get the following warning in journald's output when trying to log into kde via sddm:

Starting User Manager for UID 1000...
user@1000.service: Failed to determine user credentials: Invalid argument
user@1000.service: Failed at step USER spawning /usr/lib/systemd/systemd: Invalid argument
user@1000.service: Failed with result 'protocol'.
Failed to start User Manager for UID 1000.

Starting the DE fails and shows only the requester 'cannot sync to dbus environment'.

Downgrading to systemd 239.370-1 via

pacman -U libsystemd-239.370-1-x86_64.pkg.tar.xz systemd-239.370-1-x86_64.pkg.tar.xz systemd-sysvcompat-239.370-1-x86_64.pkg.tar.xz

solves the issue and the logins work again.
This task depends upon

Comment by Dave Reisner (falconindy) - Sunday, 06 January 2019, 02:22 GMT
Similar to  FS#55964 , you're probably running into new sandbox settings that are getting in your way. I'd suggest bisecting the sandboxing options that were added between v239 and v240.
Comment by Heinrich Siebmanns (Harvey) - Sunday, 06 January 2019, 15:59 GMT
You're probably right, but this is far beyond my knowledge :( I would be willing to test any suggestions but that is all I can do.
Comment by Dave Reisner (falconindy) - Sunday, 06 January 2019, 16:47 GMT
Well, here's the diff between v239 and v240:

Please remove the sandboxing options one by one (or remove them all and re-add until login breaks).
Comment by Heinrich Siebmanns (Harvey) - Monday, 21 January 2019, 16:27 GMT
Quote: Showing 1,975 changed files with 100,403 additions and 46,728 deletions
Sorry, but this is nothing I can do without help. I can't even identify a 'sandboxing option'. Since downgrading does not work anymore I have switched all machines back to local login. Don't get me wrong, I am not trying to avoid the work but this is nothing I can handle on my own.
Comment by Dave Reisner (falconindy) - Monday, 21 January 2019, 16:52 GMT
The interesting change is the one service file for systemd-logind.service (which the link i gave you is meant to point to).

I don't know how to get github to show the one file alone. You could:

$ git clone git://; cd systemd; git diff v239..v240 -- units/

Or, to see individual changes:

$ git log -p v239..v240 -- units/
Comment by Heinrich Siebmanns (Harvey) - Monday, 21 January 2019, 18:27 GMT
Ok, so I tried again.
Just before I begin: FWIW, the login to the console for my NIS users _is_working_. Just the Display Managers sddm (and gdm as well - I tested this before) bail out. So no DE - it falls back to the greeter with a big dialogbox from xorg: 'Could not sync environment to dbus'
I went ahead and changed all new settings in systemd-logind.service file to be mostly unrestrictive. Then I tried again (yes, reboot to be sure..) Same effect. My journalctl file shows this
systemd[582] user@1001.service: Failed to determine user credentials: Invalid argument
systemd[582]: user@1001.service: Failed at step USER spawning /usr/lib/systemd/systemd: Invalid argument
systemd[1]: user@1001.service: Failed with result 'protocol'.
systemd[1]: Failed to start User Manager for UID 1001.

I even changed both systemd-logind.service and user@.service back to the content of V239. Same effect.

I am at an end here, at least for today. My educated guess rather points to a real systemd bug. Why? 'Invalid Argument'.
Comment by Heinrich Siebmanns (Harvey) - Wednesday, 23 January 2019, 18:49 GMT
Seems like someone else with more knowledge has sorted this out:
Short version:
the commit a8b627aaed409a15260c25988970c795bf963812 is to blame