How do I identify why my login hangs for 20 seconds at startup?

Question

I've done something (I can't remember what) and now when I log in, just after entering my details, I see the background with my mouse cursor and nothing happening. Then, after about 20 seconds (presumably a timeout) the hard drive keeps loading and I get my desktop.

I tried install bootchart2:

apt-get install bootchart2 pybootchartgui

I followed their instructions here and added the following line to /etc/default/grub:

initcall_debug printk.time=y quiet init=/sbin/bootchartd ...

when I run update-grub I get the following error message:

/usr/sbin/grub-mkconfig: 12: /etc/default/grub: initcall_debug: not found

Answer 1

This type of issue can be tricky to debug. For starters it's helpful to isolate it to either a network or HDD access issue.

This is done by eliminating potential causes until you're left with the culprit.

Background

Before we get started we'll be making use of several applications that you may need to install. I'm not going to detail how to do this, I'm assuming you know how to install applications and will do so when required to perform a particular step.

Also we'll be making use of the system's console. To access it do the following: Ctrl + Alt + F2. You can use a similar keyboard combo to switch back to your primary display where your graphical desktop is. That would be this key combo: Ctrl + Alt + F1.

Networking

Using the app nethogs is a good place to start. I like to use it since it will show you the applications that are trying to access the network. Perhaps one of these applications is causing the hanging.

Before we can use nethogs we need to determine which network interface is being used by our system. Here are the ones I have on my laptop:

$ ip -o link show | cut -d" " -f2
lo:
em1:
wlp3s0:
virbr0:
virbr0-nic:
vboxnet0:

I know from experience that my wireless is wplp3s0. The ethernet is em1. Let's start with WiFi.

$ sudo nethogs wlp3s0

Resulting in this type of output:

NetHogs version 0.8.0

  PID USER     PROGRAM                      DEV        SENT      RECEIVED       
979   saml     ../bin/google-chrome-stable  wlp3s0     1.943       2.547 KB/sec
2376  saml     /usr/bin/pidgin              wlp3s0     0.000       0.000 KB/sec
21789 saml     ssh                          wlp3s0     0.000       0.000 KB/sec
9618  saml     ssh                          wlp3s0     0.000       0.000 KB/sec
10267 saml     ssh                          wlp3s0     0.000       0.000 KB/sec
?     root     unknown TCP                             0.000       0.000 KB/sec

  TOTAL                                                1.943       2.547 KB/sec 

Once we've isolated the issue to a few PIDs that appear to be lopsided in having a lot of SENT data without any receiving data, we'll need to dive in deeper and use strace to try and see what aspect of this network access is getting hung up. To accomplish this you can use strace like so:

$ strace -s 2000 -o somepid.log -p <PID>

Where <PID> is one of the process IDs identified from nethogs.

Disk I/O

If we've determined that the issue isn't with our network, the next place to explore would be looking to see if a process is having issues accessing the HDD and getting blocked in some fashion.

This can be trickier to debug but you'll likely make use of tools such as lsof, strace, and fatrace to further refine your search.

Anything else?

One place where you can fairly quickly determine if something is suspect is to disable any applications from starting up when you log in. To do this under GNOME you can launch this dialog: gnome-session-properties.

                    

Within this dialog I'd attempt to disable everything or applications you think are suspect and start doing reboots to see if the issue goes away.