ubuntu 8.10 server running ssh, vsftpd, apache2, smb.
Boot to level 3 only (MultiUser, no GUI). I do not have vnc or any other graphical process running.
This is a Linux Server for network services, I almost never use the keyboard and use the monitor even less.

My problem is ssh login takes over a minute after user/password. Other Linux machines take seconds to present a prompt. This ubuntu 8.10 server takes minutes.

Starting a 2nd shell (/bin/bash) or switching users (su -) is not as long but it is still 10-15 seconds, much longer than a comparable FC5 setup.

It is not the bash login scripts. The delay appears to happen after user/pw and before /bin/bash.

Does anyone else have issues with ubuntu 8.10 server taking so long to login?

somethign like that is often DNS related, or potentially via timeouts to other remote services, like user directory lookups... are you using ldap, nis or something? anythign in dmesg / /var/log/messages?

I have been getting the:

"atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly."

in my log files.

I had a similar problem on several FC5 builds. The problem according to web forums is the SATA and SCSI driver. I know it does not make sense that keyboard and harddrive are linked but they are. It seems that when the SATA Driver Build in the kernel move out of Device Drivers->SCSI->Low Level drivers to its own area under the ATA section after Kernel 2.6.19.

I will try to update kernel and see if problem persist.

A reboot does seem to clear the problem.
This suggest that a process was eating CPU cycles and slowing the system down.

I also remove the exim4 mail server (not required).

This is a relatively slow machine (1GHz Pentium3, 512M RAM, HD=480GB); I use it as a network server since I don't need GUI just http, ftp, SMB (file and information server).

Any CPU/memory hog would be more noticeable on a slower machine. It is hard to meter since the problem occurs when logging on or starting a /bin/bash

For now the problem has gone away with a reboot.
but it is troubling that a ubuntu server distribution has this problem. If I get more details (ps aux, etc.) I will post.

I would hate to be regulated to a MS Windows solution of rebooting often to get things running back to peak.