[plug] Slow login

[James Devenish]

In message <380-220048621144353592 at westnet.com.au>
on Sat, Aug 21, 2004 at 10:43:53PM +0800, Jim Householder wrote:
> >>On Thu, 19 Aug 2004, nofixed wrote:
> >>> Can anyone shed light on why it takes so long to login to MDK 10?
> >>> 200MHz cpu, 81MB ram, 2.6.3-7 kernel, text-mode login.
> I need to keep looking.  I removed or commented all references to
> 'floppy' in /etc/modules.devfs and /etc/modprobe.devfs.  The errors
> went away, but the delay remained. I suspect a file permissions
> problem since there is no delay for root. The questions above remain.

Jim, are you able to "pull a Craig" and show us copious output from the
`ps` and `top` utilities? These may indicate either (a) which processes
are delaying your login by consuming CPU/disk resources or (b) which
processes are delaying your login by "waiting for something". I haven't
thought about the specifics, but my idea runs something like this (I
don't know if you are comfortable implementing this yourself or whether
you would like specific assistance):

 - The basic idea is that you need to run some process-monitoring tools
   in the background while you log in. These tools will produce
   diagnostic output during your protracted login, and you can analyse
   the results once the login is complete.
 - Choose how you are going to set up the background tools. You could
   either log in once, set them up in the background, logout, then log
   back in. Alternatively (my preferred option) you can log in twice
   concurrently and monitor one login using the other. I will refer to
   these logins "login #1" and "login #2". For example, you could log in
   once using SSH as login #1 (note: does SSH login take ages, or is it
   only the console login that takes ages?) and then use a text console
   as login #2. Alternatively, you could prepare to login twice using
   two different virtual text consoles.
 - Log in to your machine via some method, such as SSH or a virtual text
   console. Tolerate the protracted login. I will refer to this as login
   #1. Set up the `top` programme to sort by CPU usage and dump its
   output to a file repeatedly once every second. Do the same with the
   `ps` programme, being sure to show the "wchan" field (see posts from
   Craig Ringer for examples of how to do this). You may wish to enable
   the tree/forest/hierarchical display to show which are the leaf
   processes. You might also wish to limit the `ps` output to show only
   those processes running for login #2. To do this, you will need to
   "predict" which TTY will be used by your second login. If you are
   using virtual consoles then this is easy to predict, as the TTY name
   is printed at the top of the getty display. To limit the output of
   `ps`, add the option '-t ttyp2', for example, if your second login
   will be on the second virtual text console. 
 - Now, log in on the virtual text console that you chose earlier. This
   is login #2. It will take ages, but `top` and `ps` will be collecting
   information.
 - Once the login is complete, switch back to login #2 and kill the
   `top` and `ps` processes.
 - Look at the logged output and be either enlightened or disappointed.