Killall -HUP?

[Verwijderd]

Gewoon uit nieuwsgierigheid... Je leest overal waar Linux staat ook -HUP Waar staat -HUP nou voor? Ik gebruik Debian, maar ik ben er nogsteeds niet achter. In de man kan ik ook nix vinden helpie!

[blaataaps]

HUP is HangUP, wordt bij daemons gebruikt om ze te laten restarten en configs opnieuw lezen.

[Verwijderd]

Nou, mooi! Weet ik dat ook weer!

[VyperX]

Het is (dacht ik) ook hetzelfde signal dat aan de processen wordt gegeven op het moment dat een user uitlogt. (*could be wrong on this one*)

[kenneth]

Om preciezer te zijn: oorspronkelijk komt het uit de tijd dat men nog veel met echte terminals werkte, inbellen en al die zut. Dus als je ophing (Engels: to Hang UP ), dan werd er naar de sessie een signaal gestuurd dat er opgehangen was.
Kort gezegd: SIGHUP = verbinding kwijt.

[Verwijderd]

Kort gezegd: SIGHUP = verbinding kwijt.

kill -SIGHUP en kill -HUP
hebben toch een net iets ander doel bij uitvoering
'k weet allen niet meer waaar ik wat gebruikte. Wie
kan hier iets meer over kwijt ??

[kenneth]

Op woensdag 27 februari 2002 13:32 schreef Conar het volgende:

[..]

kill -SIGHUP en kill -HUP
hebben toch een net iets ander doel bij uitvoering
'k weet allen niet meer waaar ik wat gebruikte. Wie
kan hier iets meer over kwijt ??

blaataaps kan dat

Op woensdag 27 februari 2002 12:30 schreef blaataaps het volgende:
HUP is HangUP, wordt bij daemons gebruikt om ze te laten restarten en configs opnieuw lezen.

SIGHUP heeft er in de loop der tijd een doel bijgekregen. Wat ik boven neerzette is alleen de oorsprong. Het signaal werd niet door 'kill' verstuurd, maar door de kernel.
Ik kan ook kill -11 4354 doen, en zo een segmentation violation genereren, maar dat betekent niet dat dat echt gebeurd is

[Verwijderd]

En wat is NOHUP dan voor'n beest?

[deadinspace]

Op woensdag 27 februari 2002 17:12 schreef Conar het volgende:
En wat is NOHUP dan voor'n beest?

nohup is een programmaatje dat het progamma dat je erachter opgeeft uitvoert, waarbij het ervoor zorgt dat het programma SIGHUP negeert.

code:

nohup programma

draait programma, waarbij programma dus niet af zal sluiten als het een SIGHUP krijgt.

[Liegebeest]

oftewel:
als het goed is blijft het doorlopen, ook al zet je je terminal/SSH/telnet sessie uit

[jeroen|IA]

(SIG)HUP is inderdaad hangup. Dat signaal kun je bijvoorbeeld naar een shell sturen om te simuleren dat de user uitlogt (veel netter dan alle processen bij elkaar zoeken en individueel afschieten), of, preciezer, de connectie met de terminal is verbroken. Omdat daemons niet aan een terminal hangen hebben ze daar het HUP signal een iets andere betekenis gegeven: herlees je config file (en interpreteer de wijzigingen natuurlijk).

[Newjersey]

killall -9 $PROGRAMMA = toch hetzelfde als kill -HUP $pid

[imdos]

En TERM zal dan wel terminate zijn

Die gebruik ik nog wel eens om het echt af te schieten

[grep]

typ eens:

man 7 signal

Handig lijstje. Uitprinten en boven je bed hangen

[Kettrick]

Op woensdag 27 februari 2002 22:55 schreef Newjersey het volgende:
killall -9 $PROGRAMMA = toch hetzelfde als kill -HUP $pid

-9 is hard onderuit schoppen.
-HUP is iets aardiger.

[jeroen|IA]

Op woensdag 27 februari 2002 22:55 schreef Newjersey het volgende:
killall -9 $PROGRAMMA = toch hetzelfde als kill -HUP $pid

NEEJ!

onthou maar gewoon dat je kill -9 niet moet gebruiken; iedereen die je van het tegendeel probeert te overtuigen probeert gewoon stoer te doen met de linux/unix kennis die hij net uit eoa newbie guide heeft opgedaan.

[deadinspace]

Op woensdag 27 februari 2002 22:55 schreef Newjersey het volgende:
killall -9 $PROGRAMMA = toch hetzelfde als kill -HUP $pid

Nee, met de eerste stuur je een SIGKILL, met de tweede een SIGHUP. Het resultaat is met beide signals bij de meeste gewone programma's dat ze afgesloten worden, maar SIGHUP komt meer neer op 'je terminal is weg, afsluiten' (en een programma mag dat negeren), en SIGKILL is 'ga nu dood' (mag en kan een programma niet negeren).

Zie ook de output van 'kill -l' btw.

[deadinspace]

Op woensdag 27 februari 2002 23:10 schreef jeroen het volgende:
NEEJ!

onthou maar gewoon dat je kill -9 niet moet gebruiken; iedereen die je van het tegendeel probeert te overtuigen probeert gewoon stoer te doen met de linux/unix kennis die hij net uit eoa newbie guide heeft opgedaan.

Je doet alsof een SIGKILL een zonde is... Tis netter om een SIGTERM of SIGHUP te sturen en SIGKILL alleen maar te gebruiken voor processes die echt niet meer willen, maar er is in GNU/Linux iig (buiten het feit dat programma's geen kans krijgen nog settings weg te schrijven oid) geen technische reden om SIGKILL niet te gebruiken.

[jeroen|IA]

Klopt, maar ik kom maar al te vaak beginnelingen tegen die kill -9 by default gebruiken omdat ze denken dat het stoer is of zo. Dat hebben ze dan weer gehoord van een andere n00b die hun verteld heeft dat het stoer is enz. enz.

Ik blijf erbij dat een kill -9 eigenlijk relatief zelden nodig is. Twee situaties waarin mensen menen dat kill -9 nodig is: een proces dat niet luistert naar een gewone kill, staat vaak in een blocking system call te wachten en is dus sowieso niet in staat om op signalen te reageren. En <defunct> processen kun je ook niet killen, want die processen bestaan feitelijk al niet meer.

[Wilke]

Op woensdag 27 februari 2002 23:15 schreef deadinspace het volgende:

[..]

Je doet alsof een SIGKILL een zonde is... Tis netter om een SIGTERM of SIGHUP te sturen en SIGKILL alleen maar te gebruiken voor processes die echt niet meer willen, maar er is in GNU/Linux iig (buiten het feit dat programma's geen kans krijgen nog settings weg te schrijven oid) geen technische reden om SIGKILL niet te gebruiken.

Ja die is er wel. SIGTERM vraagt een programma netjes zichzelf af te sluiten, het is mogelijk om het signal af te vangen en dan bv. nog even al je files te closen, netwerkverbindingen af te sluiten en in het algemeen dus alle 'state' in een welgedefineerde, consistente toestand achter te laten.

SIGKILL doet iets heel anders - een SIGKILL krijgt het programma zelf nooit te zien. Het is gewoon zeer simpel wat er wel gebeurt: staat het programma in de run-queue? Not anymore... het hele proces-nummer wordt gewoon weggegooid uit de proceslijst, *alle* geopende file descripters (dus files maar ook andere devices) worden vanzelf gesloten, en al het geheugen wat bij dit proces hoorde wordt vrijgegeven.


Had het programma data op disk staan en was het bv. net bezig deze bij te werken, dan kan dit dus na een kill -9 in een inconsistente toestand zijn. Gebruikte het programma shared memory samen met een ander prog en had het net een deel van het geheugen gelockt? Die lock is weg, maar er is geen garantie dat het shared mem in een 'geldige' toestand is (die lock gebruik je uiteraard niet voor niets!).


Ziedaar, plenty technische redenen om het NIET te doen, tenzij een proces sowieso al hartstikke dood is en geen enkele reactie meer geeft op wat dan ook (bv SIGTERMs, etc.)

[Wilke]

Simpel gezegd: doe jij killall -9 mysqld op een draaiende MySQL server, dan is er geen enkele garantie dat je mysql daarna nog kunt starten.

Toegegeven, 999 van de 1000 keer gaat het vast wel goed omdat er op dat moment niet werd geschreven in de database, maar dat is natuurlijk geen garantie

[deadinspace]

Op woensdag 27 februari 2002 23:18 schreef jeroen het volgende:
Klopt, maar ik kom maar al te vaak beginnelingen tegen die kill -9 by default gebruiken omdat ze denken dat het stoer is of zo. Dat hebben ze dan weer gehoord van een andere n00b die hun verteld heeft dat het stoer is enz. enz.

Ik blijf erbij dat een kill -9 eigenlijk relatief zelden nodig is.

True. Hoewel ik hem vroeger voor Netscape 4.45 ofzo behoorlijk vaak nodig had.

Op donderdag 28 februari 2002 00:44 schreef Wilke het volgende:
Ja die is er wel. SIGTERM vraagt een programma netjes zichzelf af te sluiten, het is mogelijk om het signal af te vangen en dan bv. nog even al je files te closen, netwerkverbindingen af te sluiten en in het algemeen dus alle 'state' in een welgedefineerde, consistente toestand achter te laten.

Zoals je zelf al even later aangeeft: de kernel closed filedescriptors (waar netwerkverbindingen ook onder vallen) als een prog afsluit (al dan niet door SIGKILL).

Had het programma data op disk staan en was het bv. net bezig deze bij te werken, dan kan dit dus na een kill -9 in een inconsistente toestand zijn.

En daarom schreef ik:

Op woensdag 27 februari 2002 23:15 schreef deadinspace het volgende:
Je doet alsof een SIGKILL een zonde is... Tis netter om een SIGTERM of SIGHUP te sturen en SIGKILL alleen maar te gebruiken voor processes die echt niet meer willen, maar er is in GNU/Linux iig (buiten het feit dat programma's geen kans krijgen nog settings weg te schrijven oid) geen technische reden om SIGKILL niet te gebruiken.

Gebruikte het programma shared memory samen met een ander prog en had het net een deel van het geheugen gelockt? Die lock is weg, maar er is geen garantie dat het shared mem in een 'geldige' toestand is (die lock gebruik je uiteraard niet voor niets!).

Daar heb je een punt dat ik niet genoemd hebt ja (maar meestal is shared mem van forks van hetzelfde prog en als je toch SIGKILLs uitdeelt dan wil je die meestal ook dood, of shared videoram, maar das niet zo'n ramp).