30 seconds delay when login - gnome-pty-helper locks utmp [WORKAROUND]

UNIX kezdő

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…

( batagy | 2010. 01. 25., h – 17:03 )

Három kérdésem lenne:
1) A gnome-pty-helper biztonságosan letiltható? Én most letiltottam a futtatási jogot, de ki tudja még mit csinál az az alkalmazás?

2) Mi pontosan a feladata az utmp fájlnak? Úgy értem, ez csak nyilvántartja a jelenlegi bejelentkezéseket és a használt terminálokat a who és finger parancs számára, mintegy egyfajta log fájl, vagy az utmp részt vesz a pseudo-terminálok kiosztásában is?

3) Az umtp fájlt hogyan tudom biztonságosan kitisztítani?
A "cat /dev/null > /var/run/utmp" nem okoz gondot? Nehogy aztán örökre mindenkit kilockoljak..... Reboot-kor ennek nem kéne nullázódnia?

Kösz!

Nem csak a finger es a who hasznalja, hanem a last is (utobbinak megadhato parameterul, hogy melyik file-bol olvasson). Szoval rebootkor nem nullazodik, a logrotate szokta idonkent gyomlalni (mondjuk havonta), es 1-2 honapra visszamenoleg altalaban megmarad.

--
"Apple have scrapped their plans for releasing Childrens iTouch after realision the iTouch Kids was not a good product name." - sickipedia

( hrgy84 | 2010. 01. 25., h – 21:07 )

A megoldasod valoszinuleg el lesz utasitva, espedig azert, mert egyfelol a gnome-pty-helper nem a gnome-terminal csomag resze, hanem a vte-e, igy gyakorlatilag minden mas, vte-n alapulo progit eltorsz, masfelol pedig a sgid (es nem suid!) jogra epp azert van szuksege, hogy irni tudjon a utmp fajlba.
En inkabb ugy fogalmaztam volna meg a bugot, hogy utana kellene jarni, mi a pontos problemaja a gnome-pty-helpernek, amit itt leirsz, az egy nagyon csunya workaround, boven nem megoldas.

En pl. kiprobaltam volna, hogy mi van, ha az ominozus utmp fajlt atteszem mashova, es hagyom, hogy egy uj letrejojjon (vagy csinalok egyet install -o root -g tty -m 0664 /dev/null /var/run/utmp)
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szia!

Igaz, egyetértek veled. Ez valóban csak workaround. Az igazi megoldás és a root cause megtalálása az lenne, hogy a gnome-pty-helper miért nem lép ki és miért fogja az utmp-t. A szöveget és a topik címét ennek megfelelően módosítottam.

De éppen azért tettem fel ide, hogy ezek a további kérdések felszínre kerüljenek. :)

( batagy | 2010. 02. 05., p – 11:42 )

Egy kis hozzáadott infó még:

A "finger" és "pinky" parancs az utmp fájlból veszi ki az információt, mégpedig azokat a sorokat írja ki, ahol a login type [7]-es jelzésű. Az "utmpdump /var/run/utmp" kimenetében az első oszlop jelenti a login type-ot. Ezek közül a [7]-es jelenti a User process-t. Ami 7-esen áll, azt listázza ki a finger és pinky. A login type-ok egyébként:
#define UT_UNKNOWN 0
#define RUN_LVL 1
#define BOOT_TIME 2
#define NEW_TIME 3
#define OLD_TIME 4
#define INIT_PROCESS 5
#define LOGIN_PROCESS 6
#define USER_PROCESS 7
#define DEAD_PROCESS 8
#define ACCOUNTING 9

Nekünk nagyon sok, az utmp-ben beragadt 7-es státuszú login volt, ezért mutatott a finger már régen nem érvényes loginokat.

érdekességképpen megjegyzem, hogy a "who" parancs máshonnan vagy máshogyan szerzi az infót, mert az nem mutatta ezeket loginokat. A "who" éppen az ellenkezője volt, alig mutatott valamit, nem mutatta hogy ki van belépve.

Az utmp fájl kitisztítása:
rm /var/run/utmp

Majd reboot során a rendszer újra létrehozza, a megfelelő bejegyzésekkel.

( batagy | 2011. 02. 11., p – 18:14 )

Még hozzáadott infó:
SLES11 esetén a gnome-pty-helper máshol van. Itt:
cd /usr/lib/vte/
ls -l
chmod 644 gnome-pty-helper
ls -l