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
Opened by 3ndymion (3ndymion) - Friday, 13 March 2020, 18:54 GMT
Last edited by Christian Hesse (eworm) - Friday, 27 March 2020, 19:50 GMT
|
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
Friday, 27 March 2020, 19:50 GMT
Reason for closing: Fixed
Additional comments about closing: systemd 245.3-2
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
[1] https://github.com/systemd/systemd/issues/15105#issuecomment-599084974
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.
loginfail_XFCE_EDITED.log (153.4 KiB)
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.