Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

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

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#65825 - [systemd] Can no longer log in after update to 245-2

Attached to Project: Arch Linux
Opened by 3ndymion (3ndymion) - Friday, 13 March 2020, 18:54 GMT
Last edited by Christian Hesse (eworm) - Friday, 27 March 2020, 19:50 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Hello all. I run Arch Linux with KDE desktop, & after getting an update to systemd 245-2 over a week ago, I can no longer log in to the system. After entering my password in SDDM, an X message comes up saying "Could not sync environment to dbus". It stays stuck there. I can only log in to the TTY. Restarting SDDM does not help. Moving the ~/.cache, ~/.config, & ~/.local directories out to let the system make new ones does not help. An upgrade to systemd 245-3 does not help. I do not recall seeing dbus getting updated. I thought maybe the problem is SDDM, but...

I also run Arch Linux on another machine with XFCE desktop. A few days ago, I got the update to systemd 245-2 on that one too. Lo & behold, I can no longer log in to this machine either. XFCE uses LightDM, & the same problem is now happening, so the problem is not the display manager. After entering my password on this one, a message comes up saying "Unable to contact settings server Could not connect: Connection refused".

Both of my Arch Linux installations are now down, & it seems that systemd is definitely the cause. I haven't found much useful info after some internet searching, so any help would be greatly appreciated. I can't imagine that I'm the only one going through this. I am including the relevant parts of the journald logs after the login attempts on both machines. I have both logs complete from bootup if needed, though I didn't see anything suspicious before trying to log in.

Thank you for looking at this. I marked this as critical, but more important is to stay safe in this time of global epidemic. Peace & one love to all.


Additional info:
* package version(s)
systemd >= 245-2

* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:
update to systemd 245-2
This task depends upon

Closed by  Christian Hesse (eworm)
Friday, 27 March 2020, 19:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd 245.3-2
Comment by loqs (loqs) - Friday, 13 March 2020, 20:29 GMT
Can you login to another user account that has a username that starts with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes?
Comment by 3ndymion (3ndymion) - Friday, 13 March 2020, 21:07 GMT
OK, I will try it later when I get back.
Comment by 3ndymion (3ndymion) - Saturday, 14 March 2020, 00:19 GMT
OK, I added a new user john. john can log in. I added a new user 1user. 1user cannot log in, gets same errors as listed above. : (

I guess I am the only one going through this after all. I won't be back until Monday, but is there no way I can get around this??? I am completely locked out of both of my Arch Linux installations now, & totally without any warning. Systemd has caused me much suffering in the past, but never like this. This is a bit devastating to me, well kind of anyway, since I multi-boot different distros. In all the years I've been using different Linux distros, I've never been locked out like this.

What exactly did systemd suddenly change to do this??? All the programs like useradd can use a badname option, & even manually creating a username like mine is no problem with /etc/passwd & the rest of the system. Isn't there a way to tell systemd to use a badname option, or even just the UID number??? If anyone can hint me to whatever new setting systemd is using, it would be greatly appreciated.

I apologize for filing this bug report only to find out that I'm probably the only one hit by it. I know an issue like this is silly & unimportant to anyone, but I really disagree with enforcing such a thing so strongly. Actually, I just found the systemd bug reports. Maybe I can file the issue there next week & hope they don't get mad at me. I found someone else who seems to be having the same problem. Please see here: https://github.com/systemd/systemd/issues/15090
Comment by AK (Andreaskem) - Saturday, 14 March 2020, 19:59 GMT
This is a guess, but I would not be surprised if the new userdb mechanism does not accept bad user names. If a comment I read on the systemd bug tracker [1] is accurate, systemd should fall back to the previous user management mechanisms in its absence. Those might still accept your user name. You could maybe try to stop systemd-userdbd.socket and systemd-userdbd.service before trying to log in? Not sure if that would be enough to test my theory.

[1] https://github.com/systemd/systemd/issues/15105#issuecomment-599084974
Comment by 3ndymion (3ndymion) - Tuesday, 17 March 2020, 00:27 GMT
OK, I'm back again. Thanks for mentioning those things. I tried stopping both of them & restarting the display manager, & this completely failed. Nothing changed. I still could not log in with the display manager. I tried restarting the display manager & logging in multiple times after stopping the systemd-userdbd socket & service, & it failed the same way every time. I even tried disabling both of those things & rebooting, but after the reboot, they were both running again even though they were disabled.

I'm going to report this on the systemd github issue tracker. I expect it to get shot down immediately, but I'm going to try anyway. Since other people seem to be going through this problem as well, maybe some good will come from it.

For whatever good it may be worth, I'm also attaching my full boot logs here. I only edited out some UUIDs that I found in them.

Edit: Attached the files.
Comment by loqs (loqs) - Tuesday, 17 March 2020, 00:34 GMT
Although 15090 looks very similar it was for an account with the login name davis which does not have the same validity issue.
Comment by 3ndymion (3ndymion) - Tuesday, 17 March 2020, 01:53 GMT
Oh, I see. I don't really know the details of how systemd works while a user is logging in, but to my untrained eyes, it seems like systemd is disagreeing with the rest of the system now. In looking through the logs, it seems that the login manager successfully authenticated the user to log in, but then systemd jumps in & disagrees. If a user already exists in the system, & is successfully authenticated to log in by the login manager, why would systemd jump in & say "Nope, I'm overriding your authorization"??? That is something that should not ever happen.

I think that if an already existing user is authenticated to log in by the login manager, then that should be it. Systemd should not jump in disagree. The different components must work in sync with each other. Does that mean that systemd is creating & using a different database than the rest of the system??? If that is the case, it will definitely lead to problems. There should only be 1 database that all login components can use & agree upon.

I also think that if there is a concern about a user with a bad name, then that concern should be made during the time of user creation, & not while logging in an already existing user. If a user already exists, they must be allowed to log in. Again, this goes with the idea of all components working in sync with each other. The programs that create user accounts, like useradd, allow a user to create an account with a "bad name". At that point, the user already knows the warnings that some programs may not work correctly. If the user creation programs allow such an option, than it should be expected that the user will always be able to log in to the system regardless of "bad name" or not.

If systemd is going to insist on refusing such logins, than all user creation programs must be changed to completely remove any type of "bad name" options so that all components are working in sync with each other. But changing multiple programs is not the sensible option to take. It makes more sense for systemd to allow an already existing user to log in as expected, especially since they were already authenticated to do so by the login manager.

Again, I don't know the details on how systemd works in this regard, but this is how my eyes see it. I'm not sure if this is actually the intention of the systemd developers or not, but if it is, I think the idea is a bit flawed. I certainly hope that any of the developers would rethink it, especially since falling back to the previous user management mechanism, as AK mentioned above, doesn't seem to be working.

BTW, sorry for such a long post. I tend to do that a lot & run out of spare time for the day.
Comment by loqs (loqs) - Tuesday, 17 March 2020, 01:58 GMT
https://github.com/systemd/systemd/issues/15141 thank you for opening the upstream bug report.
Comment by Eli Schwartz (eschwartz) - Friday, 27 March 2020, 18:11 GMT

Loading...