[linux] Een vastgelopen user killen

[EWS99]

Hoe kun je in linux een vastgelopen user (vanuit een putty shell of zo) killen?

[dinges]

ps aux | grep $user | awk {'print $2'} | xargs kill (-9)

kill je alle processes van $user
-9 staat tussen haakjes omdat dat niet altijd hoeft

[noNamer]

Door zijn shell te killen.

ps aux | grep username
en kill zijn shell of eventuele andere processen

[EWS99]

Dat is dus juist het vreemde, de user lijkt geen shell meer te hebben:

code:

router:/ # who
root     pts/0    Feb 11 16:38 (xxxx.xxxx.xxxx.nl)
erwin    pts/1    Feb  5 18:38
router:/ # ps aux | grep erwin
root     10215  0.0  1.8  1496  532 pts/0    S    17:50   0:00 grep erwin

[jeroen|IA]

Dat je het moederproces (de shell) van een hele zooi kindprocessen (de opgestarte commando's in die shell) killt wil nog niet zeggen dat je daar ook de kinderen mee afschiet. Dat is een veel voorkomend misverstand. Je kunt echter wel zorgen dat het moederproces (de shell dus) netjes zorg draagt dat alle kinderen worden be-eindigd door een HUP (hangup) signal te sturen naar de process leader van de process group die die shell vormt. Hiermee simuleer je het normaal be-eindigen van een login sessie door een gebruiker; dan gebeurt namelijk hetzelfde. Dit kun je doen met een ietwat afwijkende syntax van kill, namelijk kill -HUP -<PGID> (let op het minteken voor PGID)

De benodigde gegevens krijg je te zien als je (SysV style) ps -fju<user> typt. Er zal dan 1 veld "PGID" bij staan, wat dus voor process group id staat. Het proces dat bij PID, PGID en SID dezelfde waarde heeft staan is zowel process group leader als session leader, en dus ZEER waarschijnlijk de login shell. Als je dat proces een -HUP stuurt zal hij al zn kinderen netjes be-eindigen en zelf tenslotte ook eindigen.

Dus (op Solaris, maar Linux zal niet veel anders zijn) b.v.:

ps -fjujeroen | awk '$2 == $4 && $4 == $5 {print}'

levert alle process groups op waar ik een -HUP signal naar wil sturen. Dan kan ik er een klein scriptje omheen bouwen:

for i in $(ps -fju"$1" | awk '$2 == $4 && $4 == $5 {print $4}')
do kill -HUP "-$i"
done

Natuurlijk kun je er nog een heleboel foutafvanging omheen bouwen, maar ik hoop dat het zo een beetje duidelijk is. Voor mij werkt deze methode in ieder geval perfect, en netjes, zonder orphaned child processen en/of andere rondslingerende rommel.

--edit: hmm... ik had de vraag niet helemaal goed gelezen, het gaat idd waarschijnlijk om een loze entry in utmp. Niets om je druk over te maken, dat gaat vanzelf wel weg bij een reboot b.v.. Ik laat het verhaal hierboven toch maar staan, omdat het me wel handige informatie leek.

[kenneth]

Dan is er gewoon iets achter gebleven in /var/log/utmp (of waar het ook moge staan ). Er valt niets te 'killen'.

Het bestand dat de ingelogde users bijhoudt is gewoon niet meer up to date. Niets ernstigs, en als het wel ernstig is, dan wis je het bestand toch

[Verwijderd]

Op maandag 11 februari 2002 17:13 schreef dinges het volgende:
ps aux | grep $user | awk {'print $2'} | xargs kill (-9)

kill je alle processes van $user
-9 staat tussen haakjes omdat dat niet altijd hoeft

Heb jij zeker vaker gebruikt

[Newjersey]

had ik ook laatst onder debian, heb daarna gereboot (tja, uptime weg) , heb helaas ook geen andere manier kunnen vinden

[EWS99]

Op maandag 11 februari 2002 18:03 schreef mithalph het volgende:
Dan is er gewoon iets achter gebleven in /var/log/utmp (of waar het ook moge staan ). Er valt niets te 'killen'.

Het bestand dat de ingelogde users bijhoudt is gewoon niet meer up to date. Niets ernstigs, en als het wel ernstig is, dan wis je het bestand toch

Weet iemand waar dat bestand dan staat (SuSE 7.2)? (/var/log/utmp bestaat hier niet )

[Newjersey]

Op maandag 11 februari 2002 18:33 schreef hardrocker het volgende:

[..]

Weet iemand waar dat bestand dan staat (SuSE 7.2)? (/var/log/utmp bestaat hier niet )

ik denk dat ie /var/run/utmp bedoelt

[EWS99]

zou kunnen, maar zou je dat zo mogen deleten?

[Newjersey]

Op maandag 11 februari 2002 18:39 schreef hardrocker het volgende:
zou kunnen, maar zou je dat zo mogen deleten?

denk het eerlijk gezegt niet, maar je kan het proberen...

[dinges]

Op maandag 11 februari 2002 18:26 schreef Timboke het volgende:

[..]

Heb jij zeker vaker gebruikt

jeps

[EWS99]

Op maandag 11 februari 2002 18:40 schreef Newjersey het volgende:

denk het eerlijk gezegt niet, maar je kan het proberen...

Hmmz, Proberen is eigenlijk iets voor hondjes. En het is niet mijn eigen server, dussuh, een crash willen we niet meemaken

[Verwijderd]

Installeer de tool 'slay'. slay <user> en alle processen van die gare worden gekilled. Werkt ook bij root

edit:

Idd VyperX, ik was eerst

[VyperX]

Ik weet het niet zeker, maar is er ook niet zoiets als het command "slay"? (Is volgens mij niet standaard geinstalleerd though)

[deadinspace]

Op maandag 11 februari 2002 18:00 schreef jeroen het volgende:
Dat je het moederproces (de shell) van een hele zooi kindprocessen (de opgestarte commando's in die shell) killt wil nog niet zeggen dat je daar ook de kinderen mee afschiet. Dat is een veel voorkomend misverstand. Je kunt echter wel zorgen dat het moederproces (de shell dus) netjes zorg draagt dat alle kinderen worden be-eindigd door een HUP (hangup) signal te sturen naar de process leader van de process group die die shell vormt. Hiermee simuleer je het normaal be-eindigen van een login sessie door een gebruiker; dan gebeurt namelijk hetzelfde. Dit kun je doen met een ietwat afwijkende syntax van kill, namelijk kill -HUP -<PGID> (let op het minteken voor PGID)

De benodigde gegevens krijg je te zien als je (SysV style) ps -fju<user> typt. Er zal dan 1 veld "PGID" bij staan, wat dus voor process group id staat. Het proces dat bij PID, PGID en SID dezelfde waarde heeft staan is zowel process group leader als session leader, en dus ZEER waarschijnlijk de login shell. Als je dat proces een -HUP stuurt zal hij al zn kinderen netjes be-eindigen en zelf tenslotte ook eindigen.

In GNU/Linux en Solaris (SunOS 5.7) krijgen alle childs van een process gewoon een SIGHUP als je dit process killt hoor (zelfs met SIGKILL). De hele process group een SIGHUP sturen is dus niet nodig.

Als je iemands shell killed, dan zullen dus al de childs van die shell een SIGHUP krijgen en gewoon afsluiten (behalve processes die SIGHUP negeren, zoals hangende processes, lftp, screen, alles wat onder nohup draait, enz.

[kenneth]

killt slay alleen processen? Zoja, lees de thread beter: er zijn geen processen over.
Er staat alleen nog in een /var/run/utmp dat die user ingelogd is. Inconsistente informatie dus.

code:

init 6

of

code:

rm /var/run/utmp

[deadinspace]

Owja, je kunt 'echo > /var/run/utmp' proberen, dit leegt deze file, misschien dat dat werkt. Wissen zou ik niet doen.

[jeroen|IA]

Op maandag 11 februari 2002 19:14 schreef deadinspace het volgende:



[..]



In GNU/Linux en Solaris (SunOS 5.7) krijgen alle childs van een process gewoon een SIGHUP als je dit process killt hoor (zelfs met SIGKILL). De hele process group een SIGHUP sturen is dus niet nodig.



Als je iemands shell killed, dan zullen dus al de childs van die shell een SIGHUP krijgen en gewoon afsluiten (behalve processes die SIGHUP negeren, zoals hangende processes, lftp, screen, alles wat onder nohup draait, enz.

Nee. sommmige shells (o.a. Bash en de Korn shell) vangen dat af. Stukje uit manpage bash:

"When bash is interactive, in the absence of any traps, it ignores SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT is caught and handled (so that the wait builtin is interruptible). In all cases, bash ignores SIGQUIT. If job control is in effect, bash ignores SIGTTIN, SIGTTOU, and SIGTSTP."

[deadinspace]

Op maandag 11 februari 2002 21:39 schreef jeroen het volgende:

[..]

Nee. sommmige shells (o.a. Bash en de Korn shell) vangen dat af. Stukje uit manpage bash:

"When bash is interactive, in the absence of any traps, it ignores SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT is caught and handled (so that the wait builtin is interruptible). In all cases, bash ignores SIGQUIT. If job control is in effect, bash ignores SIGTTIN, SIGTTOU, and SIGTSTP."

Nou, dan geef je een SIGINT of SIGKILL aan die shell. Mijn punt was dat de childs van die shell dan gewoon een SIGHUP krijgen.

[jeroen|IA]

Als jij een sigkill aan een proces geeft is ie gelijk dood. vergelijk het maar met een nekschot. het proces heeft dus ook geen kans meer om zn kinderen nog een signaal te sturen; heck, hij heeft niet eens kans om zn filedescriptoren netjes te closen...

[kenneth]

Op maandag 11 februari 2002 23:12 schreef jeroen het volgende:
Als jij een sigkill aan een proces geeft is ie gelijk dood. vergelijk het maar met een nekschot. het proces heeft dus ook geen kans meer om zn kinderen nog een signaal te sturen; heck, hij heeft niet eens kans om zn filedescriptoren netjes te closen...

Dat laatste gebeurt dan automatisch door de kernel
Maar die children krijgen toch automatisch een SIGHUP? Ofnie

[deadinspace]

Op maandag 11 februari 2002 23:12 schreef jeroen het volgende:
Als jij een sigkill aan een proces geeft is ie gelijk dood. vergelijk het maar met een nekschot. het proces heeft dus ook geen kans meer om zn kinderen nog een signaal te sturen; heck, hij heeft niet eens kans om zn filedescriptoren netjes te closen...

Ik weet wat een SIGKILL is ja.

Die FDs worden (zoals Mitalph al zei) door de kernel geclosed.

Ik weet het hoe of wat van die SIGHUP naar de childs niet precies, maar mijn tests bevestigen dat het gebeurt. Als ik een shell (bash) met daaronder mp3blaster een SIGKILL stuur, dan sluit mp3blaster ook af. Als ik een shell met daaronder lftp of screen (beiden negeren SIGHUP) een SIGKILL stuur, dan blijven de lftp resp. screen gewoon doordraaien.

[jeroen|IA]

Op dinsdag 12 februari 2002 01:51 schreef deadinspace het volgende:



[..]



Ik weet wat een SIGKILL is ja.



Die FDs worden (zoals Mitalph al zei) door de kernel geclosed.

dat weet ik. ik wilde maar aangeven dat het proces ZELF niet in staat is om ook maar iets te doen als jij het een SIGKILL stuurt.

Ik weet het hoe of wat van die SIGHUP naar de childs niet precies, maar mijn tests bevestigen dat het gebeurt. Als ik een shell (bash) met daaronder mp3blaster een SIGKILL stuur, dan sluit mp3blaster ook af. Als ik een shell met daaronder lftp of screen (beiden negeren SIGHUP) een SIGKILL stuur, dan blijven de lftp resp. screen gewoon doordraaien.

Nou... uit deze voorbeelden maak ik dus op dat het soms wel werkt en soms niet? En bovendien: vertrouwen op een methode die vereist dat je een proces botweg afschiet met kill -9 vind ik maar niks. Een goede administator killt processen niet by default met kill -9. En trouwens: is een kill -9 <PID> zoveel ingewikkelder/langer/moeilijker/whatever dan een kill -HUP -<PGID> dan

[jeroen|IA]

Overigens zeggen we uiteindelijk hetzelfde; het gaat erom dat je het proces dat de controlling terminal heeft (i.e. de shell) duidelijk maakt dat de sessie dient te worden be-eindigd. Dit proces zal dan zelf zorg dragen voor be-eindiging van zn kinderen. En de makkelijkste manier is om het PGID van dat proces op te vragen en daar een -HUP signal naartoe te sturen.

(sorry voor nieuwe reply ipv edit: Opera doet erg irritant bij het bewerken van postings)

[Verwijderd]

uhm, dat kan toch ook met

ps -fu $user

ff PIDjes kijken en dan:

kill -9 PID#

zo deed ik het altijd...

[kenneth]

Op dinsdag 12 februari 2002 01:51 schreef deadinspace het volgende:
Ik weet het hoe of wat van die SIGHUP naar de childs niet precies, maar mijn tests bevestigen dat het gebeurt.

Omdat bash hoofd is van een process group. Als dat wordt gesloten, verliezen alle processen in dezelfde session hun controlling terminal. Geen terminal meer? -> SIGHUP

Op dinsdag 12 februari 2002 09:00 schreef splitz het volgende:
uhm, dat kan toch ook met

ps -fu $user

ff PIDjes kijken en dan:

kill -9 PID#

zo deed ik het altijd...

Heb je het topic wel gelezen? Het antwoord is al een paar keer gegeven hoor

[Verwijderd]

Op dinsdag 12 februari 2002 09:02 schreef mithalph het volgende:
Heb je het topic wel gelezen? Het antwoord is al een paar keer gegeven hoor

nope! sorry, ik heb een beetje door de posts gebladerd maar niet alles geleze...

[deadinspace]

Op dinsdag 12 februari 2002 06:04 schreef jeroen het volgende:
ik wilde maar aangeven dat het proces ZELF niet in staat is om ook maar iets te doen als jij het een SIGKILL stuurt.

Dat weet ik, maar ik wilde dus aangeven dat ondanks dat de childs toch een SIGHUP lijken te krijgen.

Nou... uit deze voorbeelden maak ik dus op dat het soms wel werkt en soms niet?

Nee, lftp en screen *negeren* SIGHUP. Daarom bleven deze processes gewoon leven.

En bovendien: vertrouwen op een methode die vereist dat je een proces botweg afschiet met kill -9 vind ik maar niks. Een goede administator killt processen niet by default met kill -9.

Dan doe je kill -HUP <PID van shell>.

Op dinsdag 12 februari 2002 09:02 schreef mithalph het volgende:
Omdat bash hoofd is van een process group. Als dat wordt gesloten, verliezen alle processen in dezelfde session hun controlling terminal. Geen terminal meer? -> SIGHUP

Ah, dus daar draagt de kernel zorg voor, net als bij het closen van de FDs.

Ik wil niet zeggen dat het sturen van een SIGHUP naar het GID geen oplossing is, maar het lijkt er dus gewoon op dat het een volkomen equivalente oplossing is van het maaien van de shell.

[mvanderkruk]

Heren, wat doen wij allemaal moeilijk !!!
Er bestaat al tijden een commando genaamd: "skill -x -u [UID]" Waarbij x het signal is dat de processen krijgen (9=SIGKILL 11=SIGSEGV etc) en [UID] het UserId is van de persoon (de loginnaam dus)

[EWS99]

Om weer even ontopic te komen.
Ik heb slay geprobeerd (no suchs file or directory), en ik heb met skill geprobeerd de user weg te halen. Geen van beide is dus gelukt .
Een andere oplossing zou zijn:
echo >/var/run/utmp kunnen zijn, alleen ben ik niet zeker van deze methode. Weet iemand of dit veilig te doen is? Reboot is eigenlijk ook geen optie, daar deze server niet van mij is.
Probleem is dat 'ps aux | grep erwin' geen processen weergeeft. Iemand nog een tip?

[kenneth]

Op dinsdag 12 februari 2002 16:57 schreef mvanderkruk het volgende:
Heren, wat doen wij allemaal moeilijk !!!
Er bestaat al tijden een commando genaamd: "skill -x -u [UID]" Waarbij x het signal is dat de processen krijgen (9=SIGKILL 11=SIGSEGV etc) en [UID] het UserId is van de persoon (de loginnaam dus)

Voor de derde keer ofzo Lees het topic:

1. Het antwoord is al gegeven
2. De oplossing was niet het afschieten van processen
3. De discussie gaat nu ergens anders over

Dank voor uw aandacht

[kenneth]

Of het veilig is? Heb het effe voor je geprobeerd op een testbak.

code:

[root@nerd root]# w
  7:05pm  up 69 days, 10:40,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY    FROM          LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/1    xxx.xxx.xxx.xx    7:05pm  0.00s  0.17s  0.04s  w
[root@nerd root]# >/var/run/utmp
[root@nerd root]# w
  7:05pm  up 69 days, 10:40,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY    FROM          LOGIN@   IDLE   JCPU   PCPU  WHAT
[root@nerd root]#

Uitloggen, opnieuw inloggen (via ssh)

code:

[root@www root]# ssh nerd
root@nerd's password:
Last login: Tue Feb 12 19:05:05 2002 from 213.201.165.50
[root@nerd root]# w
  7:05pm  up 69 days, 10:41,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY    FROM          LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/1    xxx.xxx.xxx.xx    7:05pm  0.00s  0.21s  0.05s  w
[root@nerd root]#

[EWS99]

Tnx!
Hier heb ik wat aan
En toch blijf ik het raar vinden:

code:

router:~ # who
erwin    pts/0    Feb 12 18:30 (xxxxx.xxxxxx.xxxxlo.nl)
erwin    pts/1    Feb  5 18:38
router:~ # w
  7:03pm  up 8 days, 21:50,  2 users,  load average: 0.00, 0.00, 0.00
USER     TTY    FROM          LOGIN@   IDLE   JCPU   PCPU  WHAT
erwin    pts/0    xxxxx.xxxxx.xxxx  6:30pm  0.00s  0.66s  0.08s  w
router:~ #

Het probleem is nu igv opgelost:

code:

router:~ # who
root     pts/0    Feb 12 19:05 (xxxxx.xxxxx.xxxxlo.nl)
router:~ #

Iedereen bedankt voor het meedenken!

[jeroen|IA]

Op dinsdag 12 februari 2002 16:14 schreef deadinspace het volgende:

[..]



Dan doe je kill -HUP <PID van shell>.

Dat werkt inderdaad, maar alleen als de shell zowel session leader als process group leader is. En daar ging mijn miniscriptje nou juist over. Of je dat HUP signal nou naar <PID> of -<PGID> stuurt maakt dan eigenlijk niet meer uit inderdaad, maar dat zei ik niet in mijn posting. (ok ok i admit ) Waar het dus uiteindelijk om gaat (en volgens mij zijn we het daarover al een paar postings eens, maar goed ) is dat je met 1 signal (niet -9...) naar 1 proces een hele sessie van een user kunt be-eindigen. Dat gedrag is netjes gedefinieerd voor het HUP signal:

code:

 "If a session has a controlling terminal, CLOCAL is not set and a hangup occurs, then the session leader is sent a SIGHUP. If the session leader exits, the SIGHUP  signal will be sent to each process in the foreground process group of the controlling terminal.

If the exit of the process causes a process group to become orphaned, and if any member of the newly-orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal will be sent to each process in the newly-orphaned process group."

maar of dat ook voor andere signals en voor andere situaties dan het be-eindigen van een session leader en het doorsturen van signals naar de kinderen geldt waag ik te betwijfelen. In ieder geval kun je er niet voetstoots vanuit gaan dat wanneer je een moederproces killt het kindproces meegaat.

[..]



Ah, dus daar draagt de kernel zorg voor, net als bij het closen van de FDs.

In deze situatie dus wel ja (signal naar session leader). Maar in het algemeen kun je er niet vanuit gaan dat een signal naar een moederproces wat dat proces doet be-eindigen op enigerlei wijze invloed heeft op de kindprocessen.

Ik wil niet zeggen dat het sturen van een SIGHUP naar het GID geen oplossing is, maar het lijkt er dus gewoon op dat het een volkomen equivalente oplossing is van het maaien van de shell.

dat klopt, alleen _hoeft_ een shell geen session leader te zijn en hoeft de session leader niet noodzakelijkerwijs een shell te zijn. Mijn punt is dat je beter netjes het HUP signal kunt gebruiken dan SIGKILL, omdat je daarmee de normale situatie dat een gebruiker zn sessie be-eindigt simuleert.