Home / server / Questions / 230861
In Process
Jamie
Asked: 2011-02-04 13:40:40 +0800 CST

Why are my log in times taking so long in Linux?

  • 772

In recent weeks, login times on my Ubuntu server have started timing out; both through SSH and the local command line console. Examination of the /var/log/auth.log files yields nothing interesting.

How can I diagnose long log in times on my Ubuntu server?

I should mention, also, that no updates have been performed since the problem has started, and that the /, /boot/ and /usr/ file systems are mounted as readonly.

[Edit] This is a stand alone machine, so it doesn't authenticate with Active Directory, LDAP etc. Also, the login prompt is responsive, as is the password prompt. Upon typing the password then CR, I'll timeout. After four a five tries, I will be able to login, although I'm worried this will start taking longer.

linux login timeout

6 Answers

  1. Quite often this is due to a reverse DNS lookup of your host IP.

    Make sure your client IP has a reverse IP DNS record.

    See this link for more details of a work around if setting up reverse records is out of your sphere of influence.

    • 4

  2. Take a look at the UseDNS [yes|no] in the sshd_config file. If it is set to Yes there is a good chance that a delay will/can occur. Take a look here: OpenSSH FAQ especially chapter 3.3. It also points to some other possible delay causes.

    • 2

  3. This thread is old but I felt onto it seeking for answers. I give my solution here. My problem (took about 1 minutes to ssh login into my raspberry pi), was due to a corrupted .bash_history file. Since the file is read at login, this was causing the login delay. Once I removed the file, login time went back to normal, like instantaneous.

    Hope this will help some other people.

    Cheers

    • 1

  4. Perhaps your /bin/login has been replaced by an evil twin that ships your passwords offsite. If such a program is poorly written, it could be hanging and/or timing out.

    Perhaps your user's (or system-wide) shell profile/rc is running something slow

    Are logins also slow in single user (runlevel 1) mode? Are you in runlevel 5? if so, try going to runlevel 3 (if you can) and see if there's a change in login speed.

    • 0

  5. Do you have nscd running (pidof nscd)? If so, shut it down and see if it gets better. If it does get better, do rm /var/db/nscd/* and start it back up.

    • 0

  6. Most of the answers on SO and elsewhere suggested the problem was a DNS issue. On a Debian system with a very long uptime, I saw it stalled out on talking to a dbus socket (logs shown below). Turns out, restarting dbus systemctl restart dbus fixed the problem

    15:50:20.475652 connect(4, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 30) = 0 <0.000049>
15:50:20.475823 getsockopt(4, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0 <0.000025>
15:50:20.475981 getsockopt(4, SOL_SOCKET, SO_PEERSEC, 0x7f301f9a1340, [64]) = -1 ENOPROTOOPT (Protocol not available) <0.000024>
15:50:20.476135 getsockopt(4, SOL_SOCKET, SO_PEERGROUPS, 0x7f301f9af260, [256]) = -1 ENOPROTOOPT (Protocol not available) <0.000024>
15:50:20.476285 fstat(4, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 <0.000028>
15:50:20.476430 getsockopt(4, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0 <0.000025>
15:50:20.476584 getsockname(4, {sa_family=AF_UNIX}, [128->2]) = 0 <0.000030>
15:50:20.476735 geteuid()               = 0 <0.000023>
15:50:20.476868 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0AUTH EXTERNAL ", iov_len=15}, {iov_base="30", iov_len=2}, {iov_base="\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", iov_len=28}], msg_iovlen=3, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 45 <0.000037>
15:50:20.477077 gettid()                = 24520 <0.000029>
15:50:20.477234 recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="OK 2560c588f16861763b962af4580ec"..., iov_len=256}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 52 <0.000033>
15:50:20.477417 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\0\0\0\0\1\0\0\0m\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=128}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 128 <0.000033>
15:50:20.477592 recvmsg(4, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000032>
15:50:20.477751 ppoll([{fd=4, events=POLLIN}], 1, {tv_sec=24, tv_nsec=999662000}, NULL, 8) = 1 ([{fd=4, revents=POLLIN}], left {tv_sec=24, tv_nsec=999377054}) <0.000316>
15:50:20.478303 recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\16\0\0\0\1\0\0\0E\0\0\0\6\1s\0\t\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24 <0.000079>
15:50:20.478607 recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=":1.121264\0\0\0\0\0\0\0\5\1u\0\1\0\0\0\10\1g\0\1s\0\0"..., iov_len=78}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 78 <0.000074>
15:50:20.478921 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\0\0\0\0\2\0\0\0\221\0\0\0\1\1o\0\31\0\0\0/org/fre"..., iov_len=168}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 168 <0.000055>
15:50:20.479125 recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1\16\0\0\0\2\0\0\0\225\0\0\0\1\1o\0\25\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24 <0.000036>
15:50:20.479322 recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0"..., iov_len=158}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 158 <0.000064>
15:50:20.479582 recvmsg(4, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000025>
15:50:20.479754 ppoll([{fd=4, events=POLLIN}], 1, {tv_sec=24, tv_nsec=999380000}, NULL, 8) = 0 (Timeout) <25.024463>
    • 0