-   Slackware (
-   -   'Whatever' login takes ages... (

Worstje 10-03-2004 06:38 AM

'Whatever' login takes ages...
Hello all,

Since a few days all things concerning logging IN (ssh, su, sudo, hell even console) take ages. For as far I know I didn't change anything. I hoped it would disappear, but it is getting very annoying by now.

I didn't notice anything in my dmesg, nor in my other logs. I don't think it has to do with my uptime either, it is quite low since I had to reboot 3 weeks ago..

And for the record, I did check the reverse-dns 'nslookup <IP>' to check if SSH might be having that problem, but it errored out immediately as it should on my LAN.

Did anyone ever have this before? And more importantly, figure out a way to fix it? :)

Thanks for your help,


fphillips 10-03-2004 10:16 PM

hmm, only thing I can think of is maybe your disk is failing, but usually that would log errors...
You could run some tests with smartctl. What kernel is this?
Is it partition-specific (is /var on it's own partition)?
If this box is remote, does it respond to pings quickly?

Worstje 10-04-2004 09:01 AM

When reading your answer I suddenly noticed that I somehow forgot a word in my first sentence (which is in the title however). It should have read: ...all things concerning logging IN ....
I do not have any problems with harddisks (for as far I know). I apologise if I confused everyone with my mistake :o

However, in case you did understand me, I will run some tests with smartctl later. Currently downloading something which I prefer to have finished as it is rather urgent :)
The box is semi-remote: I usually access it through putty from the main family computer, but if necessary I can also use the console. The login-delay is there in either case.

The following is the output of df -lh: (yes, /var is on its own partition, hda5).


Filesystem            Size  Used Avail Use% Mounted on
/dev/hda3            1.2G  981M  158M  87% /
/dev/hda1              38M  34M  3.0M  92% /boot
/dev/hda5            1.4G  1.2G  131M  91% /var
/dev/hda6            3.7G  1.7G  1.8G  49% /usr
/dev/hda9            373M  34M  320M  10% /tmp
/dev/hda7            7.5G  5.7G  1.4G  81% /home
/dev/hda8            4.2G  1.3G  3.0G  30% /music

Pings from the family computer are <1ms.

I appreciate your help, thanks :)

fphillips 10-04-2004 12:17 PM

I did some googling, and a remedy for a slow ssh login would be to add the ip address of the other computer into each /etc/hosts file. But if you're also having the same problem after you've logged in w/ su & sudo, those wouldn't be affected by this. I'm not convinced that's the fix for your problem. Could you post the /etc/ssh/sshd_config for the box you're trying to get to.

Worstje 10-04-2004 04:43 PM

Yup I tried those but those didn't work. Also didn't seem to be my problem as it worked fine before, hell, I hadn't even rebooted when this behavior began :(


worstje@coresausage ssh $ cat sshd_config
#      $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile    .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/
#MaxStartups 10

# no default banner path
#Banner /etc/issue

# override default of no subsystems
Subsystem      sftp    /usr/libexec/sftp-server

Worstje 10-05-2004 06:21 PM

I haven't made any progress myself, but I thought it might be useful for any people who are interested to see my /etc/passwd and /etc/shadow (modified a bit naturally ;))



rpc:x:32:32:RPC portmap user:/:/bin/false
user1:x:1000:100:Name blanked,N/A,N/A,N/A,A.k.a. Doggy:/home/user1:/bin/bash
stereo:x:918:918:Stereo Toren Systeem Gebruiker:/home/stereo:/bin/bash
user3:x:1001:100:Name blanked,N/A,N/A,N/A,He's ok... atleast I think so.:/home/user3:/bin/bash
user4:x:1002:100:Name blanked,-,-,deleted:/home/user4:/home/user4/conversatie




I am unfamiliar with the syntax of /etc/shadow, and the repeating 99999 number is a bit worrying since I am not sure whether it belongs there (never looked in /etc/shadow before :rolleyes: )

Edit: I just found out that in the opposite of what my first message says, INITIAL console logins do NOT delay at all. But using anything else that wants your password from that point on (sudo, su) IS delayed.

Thanks for taking a look at it everyone! :)

Worstje 10-07-2004 12:32 PM

Made some more progress (I hope).

On suse lists I found this post: su login delay
It shed some light on the problem. I looked at the other posts too and try the things they mentioned, for as far applicaple on a slackware system :)

'bash --login' works instantly.
adding 'set -x' to /etc/profile .. shows (like the guy in the thread) a huge delay and suddenly lots of output from bash.
/etc/pam.d/ ? Cannot do, don't have it :)

In the end this person disabled LDAP. So I googled for it, but it doesnt seem like its part of slackware or manually installed, but I do see that samba and sudo have some kind of support for it (in the packagebrowser wildcard search).

Is there anyway to see what is happening between 'login' and 'shell'? And once again, I don't think it's specific to ssh, su or sudo since its happening in each of them given certain circumstances (not being inital login on console to name something).

Thanks for reading...

Worstje 10-15-2004 04:06 PM

Back I am.
Well this must be something to do with the 'windows'-network it's linked to: rebooting the box fixed everything :rolleyes:. Wish I had the possibility to have tried that before.. :)

Thanks for all the thought everyone put into this :)

All times are GMT -5. The time now is 12:27 AM.