Sziasztok!
Alábbi problémát tapasztaltam SUSE Linux Enterprise Server 10 SP2 rendszeren, leírom ide, hátha másnak segítségére lesz. Illetve további néhányt kérdést felvet.
A probléma az alábbi volt:
A szerverre való belépésnél 30 másodperc várakozást tapasztaltunk.
- SSH esetén, miután a jelszót beírtuk, 30 másodperc eltelt, mire a prompt megjött. SSH-ból a kilépés ugyanúgy 30 sec-ig tartott. A probléma a NIS user-eknél és a root-nál is egyaránt fennállt.
- Amikor ssh -vvv -vel logot készítettem, az látszott, hogy az utolsó lépésnél várakozik.
- Ha pl. a saját gépről saját magára localhost-re SSH--ztam, a 30 sec várakozás akkor is fennállt.
- XDMCP-s és VNC-s belépésnél szintén fennállt a késés.
- Azonban FTP-vel és SFTP-vel való belépéskor nem volt várakozás! A szerveren a vsftpd van telepítve.
- További érdekesség, hogy egy sima xterm ablakot indítva szintén jelentkezett a 30 sec várakozás.
- Amikor a szerveren reboot volt, az mindig megoldotta a gondot, de csak egy ideig, aztán váratlan időpontban (pár nap vagy pár óra után) a hiba jelentkezett.
- A szerveren a "who" és "finger" parancsok kimenete mindig is rossz volt (régi, már nem létező beloggolásokat mutat illetve a jelenlegieket nem mutatja ), de ezt azelőtt nem kapcsoltam össze ezzel a problémával. Ebből már lehetett volna sejteni hogy az utmp fájllal van valami gond.
Egyesek DNS feloldási hibára gyanakodtak, vagy éppen a reverse DNS feloldásra gondoltak, de nem az volt.
Amikor lsof paranccsal néztük hogy a 30 sec közben milyen fájlok vannak használva, akkor vettük észre hogy a "/var/run/utmp" fájlt birizgálja a beléptető process (pl. mingetty ha local terminálról lépünk be, sessmgr ha a Gnome indul vagy sshd ha SSH-vel lépünk be). Mivel a vsftpd-vel nem állt fönn a probléma, kipróbáltuk, hogy engedélyezzük a "session_support"-ot a vsftpd.conf-ban. A session_support opció ezt jelenti a vsftpd-nél:
session_support
This controls whether vsftpd attempts to maintain sessions for logins. If vsftpd is maintaining sessions, it will try and update utmp and wtmp. It will also open a pam_session if using PAM to authenticate, and only close this upon logout. You may wish to disable this if you do not need session logging, and you wish to give vsftpd more opportunity to run with less processes and / or less privilege. NOTE - utmp and wtmp support is only provided with PAM enabled builds.
Default: NO
Ha ezt engedélyeztük, akkor, milyen meglepő, de az FTP-vel való belépés és 30 sec lassú lett! Azaz kiderült, hogy a problémának az utmp/wtmp fájlokhoz van köze.
A probléma forrása a "gnome-pty-helper" alkalmazás, ami valaki okból nem lép ki, és a "/var/run/utmp" fájlt lockolva tartja. A "gnome-pty-helper" processek pedig egyre csak gyűlnek és az utmp fájl nem lesz írható. Emiatt minden olyan process ami frissítené ezt a fájlt, 30 másodpercig belassul.
A workaround szöveget angolul már leírtam a Novell fórumra, ide csak bemásolom.
All 30 delay problem is caused by the "gnome-pty-helper" application, that is not exiting, and begins to lock the "/var/run/utmp" file. Then any other processes that want to update the /var/run/utmp file, will be hanging for 30 seconds, as they can't write the umtp file. Needless to say this also caused that "who" and "finger" commands output were not correct, as the /var/run/utmp file contained no longer valid entried, that were not cleared also because of this problem. As I searched through for this problem, noticed this is not SLES specific, it is a problem of the gnome-pty-helper (it's child process of the gnome-terminal), and it can be present on other Linux distros.
To check the problem exist, run lsof which process uses the utmp file. You will notice a lot "gnome-pty-helper" is uses the utmp file, some of the process if locking the file, it shows by "R" in the FD column.
server:~ # lsof /var/run/utmp
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
gnome-pty 6480 usernm1 5u REG 253,3 25728 950274 /var/run/utmp
gnome-pty 13446 usernm2 5uR REG 253,3 25728 950274 /var/run/utmp
gnome-pty 26479 usernm3 5u REG 253,3 25728 950274 /var/run/utmp
gnome-pty 27539 usernm4 5u REG 253,3 25728 950274 /var/run/utmp
gnome-pty 29775 usernm5 5u REG 253,3 25728 950274 /var/run/utmp
gnome-pty 30443 usernm5 5u REG 253,3 25728 950274 /var/run/utmp
server:~ # ps -ef | grep gnome-pty-helper
usernm1 6480 6479 0 Jan19 ? 00:00:00 gnome-pty-helper
root 9772 9623 0 10:14 pts/4 00:00:00 grep gnome-pty-helper
usernm2 13446 1 0 Jan20 ? 00:00:00 gnome-pty-helper
usernm3 26479 26478 0 Jan22 ? 00:00:00 gnome-pty-helper
usernm4 27539 1 0 Jan22 ? 00:00:00 gnome-pty-helper
usernm5 29775 1 0 Jan22 ? 00:00:00 gnome-pty-helper
usernm5 30443 1 0 Jan22 ? 00:00:00 gnome-pty-helper
With the below command you get the same list, but you also get the PPID (parent process ID). Please note that most of the gnome-pty-helper processed has lost its parent, so the PPID has become 1.
server:~ # ps -f -p `fuser /var/run/utmp `
Cannot stat file /proc/6321/fd/5: Stale NFS file handle
/var/run/utmp:
UID PID PPID C STIME TTY STAT TIME CMD
usernm1 6480 6479 0 Jan19 ? S 0:00 gnome-pty-helper
usernm2 13446 1 0 Jan20 ? S 0:00 gnome-pty-helper
usernm3 26479 26478 0 Jan22 ? S 0:00 gnome-pty-helper
usernm4 27539 1 0 Jan22 ? S 0:00 gnome-pty-helper
usernm5 29775 1 0 Jan22 ? S 0:00 gnome-pty-helper
usernm5 30443 1 0 Jan22 ? S 0:00 gnome-pty-helper
You can also check the last update time of the utmp:
server:~ # date
Mon Jan 25 10:15:42 CET 2010
server:~ # ls -l /var/run/utmp
-rw-rw-r-- 1 root tty 25728 Jan 20 15:36 /var/run/utmp
If you dump the content of the umtp to human readable format, you also can check that the last update time in the umtp will match the last modification time of the file, and it is also the starting time of the gnome-pty-helper process that locks umtp (in this case PID 13446).
server:~ # utmpdump /var/run/utmp > /root/TESZT/utmpdump1.txt
Utmp dump of /var/run/utmp
To check what is the full path of gnome-pty-helper before killing all:
server:~ # readlink -f /proc/6480/exe
/opt/gnome/lib/vte/gnome-pty-helper
Then killall all hanging gnome-pty-helper processes:
server:~ # killall -9 gnome-pty-helper
Make a check it succeeded:
server:~ # lsof /var/run/utmp
server:~ # ps -ef | grep gnome-pty-helper
root 9814 9623 0 10:17 pts/4 00:00:00 grep gnome-pty-helper
server:~ # ls -l /var/run/utmp
-rw-rw-r-- 1 root tty 25728 Jan 20 15:36 /var/run/utmp
Now if you login with say SSHD, utmp should be updated.
According to GNOME-PTY-HELPER(1) (quiet old) description, gnome-pty-helper is a program that setuid application used to open a pseudo-terminal, set the permissions, ownership and record user login information. It looks that its only purpose just to update the utmp file, I don't know if it has any other function. But no much point to keep track what gnome-terminals are being used on which pseudo-terminal, so maybe the gnome-pty-helper can be disabled, at least I did it.
server:~ # cd /opt/gnome/lib/vte/
server:/opt/gnome/lib/vte # ls -l
total 16
-rwxr-sr-x 1 root tty 13072 May 18 2007 gnome-pty-helper
server:/opt/gnome/lib/vte # chmod 644 gnome-pty-helper
server:/opt/gnome/lib/vte # ls -l
total 16
-rw-r--r-- 1 root tty 13072 May 18 2007 gnome-pty-helper
Remaining issue that the current /var/run/utmp file should be cleared, to only show valid data. I don't know yet how to do this.
Above is just a workaround, and I'm not sure whether disabling the execution right of gnome-pty-helper doesn't break any other function. Also, it must be figured out why gnome-pty-helper doesn't exit properly any why locks the utmp file.
References:
gnome-pty-helper does not exit
http://linux.derkeiler.com/Mailing-Lists/Debian/2005-11/3107.html
gnome-pty-helper needed?
http://osdir.com/ml/gnome.devel/2005-11/msg00013.html
GNOME-PTY-HELPER(1)
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=fw&db=man&f…