systemd-logind slow logins

Shadow_7 · 06-16-2015, 04:57 AM

$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 May 26 01:07 /sbin/init -> /lib/systemd/systemd

$ cat /proc/1/comm
systemd

And right after bringing up the network (dhclient), my logins are back to the long delay. At least until:
# systemctl restart systemd-logind

I know a fresh install will solve this issue. For a time anyway. But this issue seems to always creep back in, in just a few months. Less than a month in this instance. In the meantime restarting systemd-logind after bringing up the network is a viable work around.

Head_on_a_Stick · 06-16-2015, 01:44 PM

This is just a theory but I think your dbus session isn't working properly.

I have noticed dbus problems with my sid system using a console log-in to a dwm session but not when using GDM to log-in to GNOME.

In Arch, there are a set of scripts supplied with the xinit package that can be called from ~/.xinitrc (~/.xsession in Debian) to start the dbus session properly when using a console log-in.

I will try copying these scripts to my Debian system later and see if this fixes my problems and post the scripts here for you to try if they do.

As systemd is new to Debian, I think the developers have concentrated on support for the desktop environments and left the pure window manager users (who tend to be more expert) to fend for themselves (as it were).

This is just a theory though.

When using systemd, what is the output of:

Code:

systemctl --failed

Head_on_a_Stick · 06-16-2015, 03:27 PM

Update: Add this snippet to the start of ~/.xinitrc (in sid) or ~/.xsession (in jessie) to start the dbus session correctly:

Code:

#!/bin/bash
if [ -z "${DBUS_SESSION_BUS_ADDRESS-}" ] && type dbus-launch >/dev/null; then
  eval $(dbus-launch --sh-syntax --exit-with-session)
fi

Shadow_7 · 06-16-2015, 07:09 PM

That sounds viable, and it does seem to be dbus. Or at least systemd-logind's relationship with dbus. But this slow to login stuff starts after bringing up the network. And it exists while still in the command line mode before ever starting anything graphical. Plus I've never had this issue on my other laptop which is 32 bit and runs basically the same everything.

$ su
# exit
$ su
(no delay after a cold boot)

$ su
(no delay)
# dhclient -4 -v eth0
# exit
$ su
(30-ish seconds till you're root again)
# systemctl restart systemd-logind
# exit
$ su
(no delay after restart of systemd-logind, after the network is up)
# exit

$ startx -- :0

It's mostly an annoyance. I mostly use multiple users to keep seperate bash histories for various tasks. Even though these machines are basically single user desktop machines. Plus having an additional gaming user helps keep the cruft at bay when you need to regain some quick storage space.

Head_on_a_Stick · 06-17-2015, 01:08 AM

Does systemd report any failed units?

Shadow_7 · 06-17-2015, 09:38 AM

I had a failed unit for user 1000 at the login prompt once, but it didn't create a log entry in any of the /var/log/ locations. And I haven't noticed it lately. The main log entry is dbus timing out, as logged in /var/log/syslog. When the long delay is active, this appears to be the delay. Oddly restarting dbus does not undo the timeout issue, but restarting systemd-logind does put things in what appears to be a normal state.

Code:

Jun 17 09:08:40 {hostname} dbus[856]: [system] Failed to activate service 'org.freedesktop.login1': timed out

This error occurs before starting X after a cold boot.

Shadow_7 · 06-18-2015, 05:43 PM

I may have found out why this is an issue. At least for me. Before systemd, I used to restart udev and dbus to make it the highest PID in the output of ps, before anything I started as a user. Yeah, it would loop back around eventually, but until that happened all of my post boot processes would be listed last (sorted by PID) in the output of ps right below dbus.

Apparently when dbus restarts (via personal script), this issue gets triggered. I had the dbus restart in my network startup script after setting up the network, which I manually execute after logging in. I commented out that part of the script and the issue does not currently get trigger after a cold boot. Oddly it takes a while after a fresh install for this to be an issue it seems.

I wonder if the triggering event is be a side effect of creating new user accounts in a chroot while /proc/ and /dev/ of the host system is shared with the chroot (as one does when doing a debootstrap install). Or maybe the triggering event is the init system upgrading from sysv to systemd as part of a regular update. It still shouldn't be an issue in my opinion, but at least I'm closer to knowing WHY it's an issue. And it isn't an issue when the install is fresh or when the init system is sysv with the unmodified script that restarts dbus.