|
systemd-logind slow logins
Using su to change users takes 30-ish seconds to change users. Except when the network is completely down. This seems to happen to my system semi-regularly and I've been fixing it by doing a fresh install. This last time it took less than 30 days. Normally it takes 3 to 6 months.
I have managed a work around/fix it would seem. # apt-get install --reinstall systemd # systemctl restart systemd-logind Before fixing the issue: # loginctl list-seats Would time out. # grep -i login /var/log/syslog May 27 12:13:14 hostname dbus[844]: [system] Failed to activate service 'org.freedesktop.login1': timed out Are but a few of the symptoms. The main usability issue being that it takes 30-ish seconds to su to another user. Issues like this one (and others) make me a little more concerned about the security of my system(s). This seems to be an issue that spans several distros. And may be amd64 specific. And may be related to installing i386 packages on said systems. The mbrola-us3 package (for espeak) in my case. The issue does not self correct once said package(s) are uninstalled. At least not until systemd is reinstalled in my case. Just putting this out there for the others that are affected. And to remind my aging self of a potential solution when it happens again. |
It seems that on reboot I have the same issue.
# systemctl restart systemd-logind Seems to be the only step needed to solve it (at each boot). If done after dhclient brings the network up. |
What is your partition layout? If you are using separate /usr it will slow down boot times.
|
/ is it's own partition, and the only partition. Boot time is not the issue. The issue is that once I bring up the network (dhclient/ethernet), when I try to su to another user, that login takes 30+ seconds (locally). As long as the network is down it's not an issue as local logins are almost instantaneous. Restarting systemd-logind fixes the login delay after bringing up the network with dhclient. (temporarily / doesn't carry over to the next boot). This isn't an issue when the install is fresh, but creaps in fairly consistently to an issue within a few months of regular updates. At least with the jessie variant, when it was still testing, and apparently now when it's the stable branch.
I tend to do fairly minimal installs via debootstrap. And boot to the console/CLI by default. At which point I do a few things manually depending on what I want to do with my computer that day. A window manager of cwm from sources, via .xinitrc and startx, and a custom kernel, 3.19+ (4.0.1 atm) are about the only exotics things with this otherwise minimal desktop-ish system. |
Have you checked /var/log/messges or dmesg to reserch problems?
|
So I rebooted to recreate the issue and check recent logs. And it's no longer an issue. Maybe it's just something that happens when you reboot after a couple weeks of uptime. It's certainly not the first time I've had this issue and probably not the last.
As mentioned in the first post, /var/log/syslog had a timeout message. And "loginctl list-seats" would time out when the issue was active. I'll check /var/log/messages the next time that it is an issue. But at the moment, not an active issue. |
Well it's back. /var/log/messages shows nothing of interest.
/var/log/syslog Code:
Jun 1 15:22:30 ...hostname... dbus[841]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'Perhaps something in /etc/dbus-1/system.conf is at fault here. That seems to be the only hit of interest in /etc/* with egrep. ---------- Post added 06-01-15 at 03:43 PM ---------- Per the log, 25 seconds from activation to timed out. |
I suppose that I shouldn't have systemd-logind and login running at the same time. Because I do after restarting systemd-logind.
I'm starting to wonder if doing system installs via chroot (debootstrap style) is the trigger? Since I did an i386 install for the old laptop on this amd64 laptop around the same time this crept up this time. I shutdown to undo the chroot and it's mount points. Since functioning in the chroot binds the host udev and stuff when using apt to install stuff post chroot setup, like a kernel to make it bootable. |
It appeared that systemd and systemd-sysv were both installed. I did an apt-get remove systemd-sysv and it did that and added other new packages. This reboot there is no login delay when su-ing between users multiple times, and I didn't have to restart systemd-logind. Maybe it'll hold this time around. There was an odd message, that doesn't appear to have made it to any of the logs. It said something about an unrecognized unit for (user)@1000.service. Shortly after logging in after a cold boot. With the user id and username of the user that I was logged in with at the time.
|
Quote:
I take it you are now using SysVinit as PID1? Post the output of: Code:
ls -l /sbin/init |
Quote:
init-+-cgmanager as listed with pstree |
Quote:
"PID1" is the first process called by the kernel after booting up: ie, init. Please post the output I have requested as this will clarify which init system you are using. |
Quote:
-rwxr-xr-x 1 root root 40648 Apr 6 13:44 /sbin/init cat /proc/1/comm init |
Quote:
You should either re-install the systemd-sysv package to switch back or run this command to make sure the switch is complete: Code:
# apt-get install sysvinit-core systemd-shim systemd-sysv- |
$ dpkg -l | grep -i systemd
Code:
ii libpam-systemd:amd64 215-17+deb8u1 amd64 system and service manager - PAM module# apt-get install systemd-sysv Odder still that running that mentions upstart. Debuntu? Or more of a curiousity. And more oddities, just to be sure that I'm running systemd-sysv at the next reboot. # apt-get install --reinstall systemd-sysv systemd Ends in: E: Couldn't configure systemd-sysv:amd64, probably a dependency cycle. Although: # apt-get install --reinstall systemd-sysv Succeeds without the E:. I guess that means that it's time to reboot and see if I have slow logins again. |
| All times are GMT -5. The time now is 06:49 PM. |