[linux] vim wil niet dood

[Verwijderd]

ik heb in mijn proceslijst van linux twee maal vim staan, die een bestand schijnen te bewerken wat er helemaal niet is.

Deze processen nemen beide 40% cpu tijd in.

killall vim en kill [pid] werken beide niet.
Ik kan de computer niet rebooten. (staat op afstand).

Wat nu?

[DeMoN]

Wat zegt ie bij "killall vim" ? (welke melding? noprocess killed?)

En doe eens "ps -auxf"

Even kijken of hij daar tussen staat. Misschien heet hij iets anders.

_{eventueel kan je "ps -auxf |grep vim" proberen maar misschien vindt ie dan niks omdat hij anders heet wat ik trouwens zeer betwijfel}

[ Voor 33% gewijzigd door DeMoN op 09-01-2003 15:04 ]

[zwik]

killall -9 vim

Misschien dat die beter werkt.

[Mark]

Let op met het adviseren van het killall commando, dit kan in sommige gevallen een iets andere werking hebben als de "standaard" functie dat hij alleen alle processen kilt met die naam (HP-UX gebruikers weten wat ik bedoel).
Kijk even met: ps ax | grep vim wat de PID's zijn van beide processen en gebruik: kill -9 pid1 pid2 (op de plaats van pid1 en pid2 vul je natuurlijke bijde PID's in van de processen).

[igmar]

Verwijderd schreef op 09 January 2003 @ 15:01:
ik heb in mijn proceslijst van linux twee maal vim staan, die een bestand schijnen te bewerken wat er helemaal niet is.

Deze processen nemen beide 40% cpu tijd in.

killall vim en kill [pid] werken beide niet.
Ik kan de computer niet rebooten. (staat op afstand).

kill -9 pid

Bovenstaand gedrag gebeurd als je de terminal waar de vim aanhangt afschiet.

[Verwijderd]

Heeft nano + vi idd ook. Zit je gewoon te werken verloopt je DCHP lease, of je internet knalt er uit. Enige oplossing is idd kill -9 <<nummerT>>

[Verwijderd]

Mark schreef op 09 januari 2003 @ 15:06:
Let op met het adviseren van het killall commando, dit kan in sommige gevallen een iets andere werking hebben als de "standaard" functie dat hij alleen alle processen kilt met die naam (HP-UX gebruikers weten wat ik bedoel).
Kijk even met: ps ax | grep vim wat de PID's zijn van beide processen en gebruik: kill -9 pid1 pid2 (op de plaats van pid1 en pid2 vul je natuurlijke bijde PID's in van de processen).

Mjah in de topictitel staat al dat het Linux betreft. Dus je hoeft niet bang te zijn dat alle processen worden afgeschoten

[moto-moi]

Verwijderd schreef op 09 January 2003 @ 15:16:
Heeft nano + vi idd ook. Zit je gewoon te werken verloopt je DCHP lease, of je internet knalt er uit. Enige oplossing is idd kill -9 <<nummerT>>

Of screen gebruiken

[Mark]

Verwijderd schreef op 09 januari 2003 @ 15:21:

[...]

Mjah in de topictitel staat al dat het Linux betreft. Dus je hoeft niet bang te zijn dat alle processen worden afgeschoten

Je kunt mensen beter meteen iets goed aanleren, mocht het ooit zover komen dat ze eens een keer op een echte Unix machine zitten te werken

[Wirf]

igmar schreef op 09 January 2003 @ 15:11:
[...]
Bovenstaand gedrag gebeurd als je de terminal waar de vim aanhangt afschiet.

Nee, dat is een SIGHUP (hangup signal) die je applicatie krijgt als je de terminal afschiet.

zo kun je ook applicaties laten doordraaien als je je terminal afschiet door "nohup gzip een_groot_bestand" te doen (bijvoorbeeld)

Ctrl-C = SIGINT
terminal dood = SIGHUP
Ctrl-\ = SIGQUIT

[/offtopic]

[igmar]

Verwijderd schreef op 09 January 2003 @ 15:21:
Mjah in de topictitel staat al dat het Linux betreft. Dus je hoeft niet bang te zijn dat alle processen worden afgeschoten

killall is en blijft gewoon een erg slechte gewoonte.

[Verwijderd]

igmar schreef op 09 January 2003 @ 18:23:
[...]


killall is en blijft gewoon een erg slechte gewoonte.

Verklaar u nader. Ik zie erg veel posts van je met een opmerking maar nooit een uitleg of onderbouwing. Ik twijfel niet aan je kennis, maar ik ben meestal wel geintereseerd in het hoe en waarom van jouw posts.

[_JGC_]

Mark schreef op 09 januari 2003 @ 17:41:
[...]

Je kunt mensen beter meteen iets goed aanleren, mocht het ooit zover komen dat ze eens een keer op een echte Unix machine zitten te werken

FreeBSD echt Unix achtig genoeg? Daar deed ik ook gewoon Killall's als wine me weer eens zat te pesten

[igmar]

Verwijderd schreef op 09 januari 2003 @ 18:38:
[...]

Verklaar u nader. Ik zie erg veel posts van je met een opmerking maar nooit een uitleg of onderbouwing. Ik twijfel niet aan je kennis, maar ik ben meestal wel geintereseerd in het hoe en waarom van jouw posts.

Omdat het een vrij gevaarlijk commando is. Nog afgezien van het feit dat killall onder andere *NIX'en een andere resultaat heeft dan men meestal wenst is het een command waar je snel aan went : Geen pid's meer opzoeken, dus men gaat vrij snel alleen maar killall gebruiken.

Een killall -KILL ssh en een killall -KILL sshd is een klein verschil, de eerste killt al je ssh sessies, maar het tweede logt je effectief gezien uit, en je komt d'r ook niet meer in.

[igmar]

_JGC_ schreef op 09 januari 2003 @ 18:58:
[...]
FreeBSD echt Unix achtig genoeg? Daar deed ik ook gewoon Killall's als wine me weer eens zat te pesten

Sja.. totdat m'n collega eens op een SCO bak remote zat een ook killall gebruikte. Het resultaat heeft denk ik geen naardere uitleg nodig

[Verwijderd]

igmar als je het verschil weet en weet dat het op bepaalde unices een compleet andere uitwerking heeft en je daarnaast ook de universele manier kent, dan is er niks verkeerd met het gebuik van killall hoor

[Wilke]

igmar schreef op 09 January 2003 @ 19:00:
[...]


Sja.. totdat m'n collega eens op een SCO bak remote zat een ook killall gebruikte. Het resultaat heeft denk ik geen naardere uitleg nodig

Mja, wat mij betreft best wel eigenlijk

Wat doet het 'killall' commando op een SCO bak of onder HP-UX dan anders dan ik in Linux of FreeBSD gewend ben?

* Wilke heeft geen idee wat nou het grote verschil is...

[Verwijderd]

Het doet een hele letterlijke vertaling van het commando Wilke

[Mark]

Als je op bijvoorbeeld HP-UX en inderdaad ook SCO lang genoeg wacht na het uitvoeren van het killall commado, dan staat de stroom nog wel op de machine, maar meer kun je niet meer vanaf een remote locatie .
Met andere woorden killed het gewoonweg alle processen behalve init, niet leuk als je fysiek niet zo makkelijk bij die machine kunt.

[Wilke]

Hmmm..praktisch.

En heeft dat dan ook nog nut, dat het standaard geinstalleerd is?

Misschien zolang je geen root bent ofzo (kun je toch alleen al je eigen processen killen), dat zal het idee wel wezen dan, of niet?

[Mark]

Uit de manpage van HP-UX 10.20

code:

 NAME
      killall - kill all active processes

 SYNOPSIS
      /usr/sbin/killall [signal]

 DESCRIPTION
      killall is a procedure used by /usr/sbin/shutdown to kill all active
      processes not directly related to the shutdown procedure.

      killall is chiefly used to terminate all processes with open files so
      that the mounted file systems are no longer busy and can be unmounted.
      killall sends the specified signal to all user processes in the
      system, with the following exceptions:

           the init process;

           all processes (including background processes) associated with
           the terminal from which killall was invoked;

           any sed -e process, if owned by root;

           any shutdown process;

           any killall process;

           any /sbin/rc process.

      killall obtains its process information from ps, and therefore may not
      be able to perfectly identify which processes to signal (see ps(1)).

      If no signal is specified, a default of 9 (kill) is used.

      killall is invoked automatically by shutdown The use of shutdown is
      recommended over using killall by itself (see shutdown(1M)).

 FILES
      /usr/sbin/shutdown

Er staat leuk in dat hij geen processen killed welke gekoppelt zijn aan de terminal waarvandaan het commando gestart word, maar laat dit nu eens alleen voor fysieke terminals gelden en geen telnet/ssh sessies...

[Verwijderd]

Leuk...Maar is de topic starter's vraag inmiddels opgelost?

[active2]

Wat de topic starter kan doen is het mamma proces afmaken dan is het ook met vim gebeurt.

En om even een reactie op killall te geven dat kun je ook op de volgende manier doen.

Je kan er ook even een oneliner van maken:

code:

kill <opties> `ps aux | grep <processnaam> | awk '{print $2}'`

En dat kun je bijvoorbeeld ook nog in een shell script neer planten met een paar argumenten.

Easy as that!

[blaataaps]

active2 schreef op 10 januari 2003 @ 09:22:

Je kan er ook even een oneliner van maken:

code:

kill <opties> `ps aux | grep <processnaam> | awk '{print $2}'`

Voor de zekerheid kun je er nog een grep -v grep tussenplakken:

code:

# ps aux | grep top
root     26940 22.0  2.4  1768  944 pts/4    S    11:03   0:00 top
root     26942  0.0  1.0  1332  424 pts/2    S    11:03   0:00 grep top
#

Omdat hij nu de grep ook af gaat schieten en ik niet weet in hoeverre hij dat zal doen voordat grep klaar is met greppen..

[grep]

blaataaps schreef op 10 januari 2003 @ 11:04:
[...]
Omdat hij nu de grep ook af gaat schieten en ik niet weet in hoeverre hij dat zal doen voordat grep klaar is met greppen..

U riep?

[Verwijderd]

killall kan ook nuttig zijn, ik heb wel eens meegemaakt dat het PID van een process wat ik dood wil snel veranderde.
dan is killall naam behoorlijk handig.
(encoden van kleine wav bestandjes en xmms enzo)

[Verwijderd]

Ja, probleem hier ook tijden gehad
ps -x |grep vi

kill -s KILL <pid>

[igmar]

Verwijderd schreef op 09 januari 2003 @ 20:01:
igmar als je het verschil weet en weet dat het op bepaalde unices een compleet andere uitwerking heeft en je daarnaast ook de universele manier kent, dan is er niks verkeerd met het gebuik van killall hoor

Dat is probleem niet: Het gevaar zit het in het niet weten, en de gevolgen daarvan.

[igmar]

Wirf schreef op 09 January 2003 @ 18:23:
Nee, dat is een SIGHUP (hangup signal) die je applicatie krijgt als je de terminal afschiet.

zo kun je ook applicaties laten doordraaien als je je terminal afschiet door "nohup gzip een_groot_bestand" te doen (bijvoorbeeld)

Ctrl-C = SIGINT
terminal dood = SIGHUP
Ctrl-\ = SIGQUIT

[/offtopic]

Het maakt niet uit hoe die betreffende terminal overlijd, HUP, KILL, QUIT, SEGV : Altijd loopt ie in een singal handler. Zo te zien een bug in de signalhandlers in vim.

[Verwijderd]

//offtopic

Als je op bijvoorbeeld HP-UX en inderdaad ook SCO lang genoeg wacht na het uitvoeren van het killall commado, dan staat de stroom nog wel op de machine, maar meer kun je niet meer vanaf een remote locatie .
Met andere woorden killed het gewoonweg alle processen behalve init, niet leuk als je fysiek niet zo makkelijk bij die machine kunt....

2 woorden: Remote webconsole... Je gaat toch geen beheer op een HP-UX machine doen via een telefoonlijntje en dan geen remote webconsole hebben??

[ Voor 76% gewijzigd door Verwijderd op 12-01-2003 16:12 . Reden: verkeerde quote.. ]

[Verwijderd]

grep schreef op 10 januari 2003 @ 11:12:
[...]

U riep?

code:

$ ps -ef | grep ora
gebruiker  2241  2227  3 22:46:51 dtc2b1p7  0:00 grep ora
  oracle   924     1  0  Jan 11  ?         0:37 ora_pmon_MC
  oracle   929     1  0  Jan 11  ?         1:08 ora_dbwr_MC
  oracle   934     1  0  Jan 11  ?         0:39 ora_lgwr_MC
  oracle   939     1  0  Jan 11  ?         0:06 ora_smon_MC
  oracle   944     1  0  Jan 11  ?         0:01 ora_reco_MC

Zoals je ziet staat je eigen grep nu ook in je proceslijstje. Stel je het volgende voor:

code:

$ ps -ef | grep ora | awk '{print $2}'
2241
924 
929
934
939
944

En dan nog een xargs kill erachteraan. Je gaat nu ook je eigen grep proberen te killen. Je hoeft niet bang te zijn dat niet alle gewenste processen worden gekilled, want de grep is al afgelopen tegen de tijd dat er daadwerkelijk gekilled gaat worden (kill: 2241: no such process).
MAAR er zou in de tussentijd een ander proces met dit pid opgestart kunnen zijn dat je dan onbedoeld killed...

[Guru Evi]

killall is idd gevaarlijk om te gebruiken, net als ctrl-alt-del enzo
kill -9 <procesid> gebruiken is het beste eigenlijk
Ik weet nog toen ik 13 jaar was mocht ik met mijn nonkel mee naar zijn werk omdat daar veel pckes stonden (Unix mainframe's) en ik mocht ff tokkelen op een machien (had een schermpje, was ingelogd als root) en ik vond niet beter dan een killall te doen (en die Unix had ook nog auto-aanvulling: mijn nickname van toen: killah: do you mean killall (y/n) ) waarna het gehele bedrijf zo'n 15 minuten moest wachten om verder te werken. That was fun (totdat ik een tegen mijn oren kreeg)

[Verwijderd]

Volgens mij is het simpel... kijk onder welke sessie de processen draaien... Draaien daar meerdere processen, kijk dan of ze actief zijn. Zijn ze actief dan alleen de vim-processen killen met het hierboven al gemelde kill -9 commando. Zijn dit de enige processen en is de sessie al langere tijd niet meer actief, bestaat de mogelijkheid dat user niet meer 'ingelogd' is, en processen zijn blijven 'hangen'.

Dit is dan dus geen probleem meer, want dan kun je alle processen van deze user elimineren, omdat de user reeds uitgelogd is.

[deadinspace]

completely offtopic:

Guru Evi schreef op 13 January 2003 @ 01:01:
(en die Unix had ook nog auto-aanvulling: mijn nickname van toen: killah: do you mean killall (y/n) )

zsh kan dat ook. Misschien had die Unix bak zelfs wel zsh.

waarna het gehele bedrijf zo'n 15 minuten moest wachten om verder te werken. That was fun (totdat ik een tegen mijn oren kreeg)

Pff, kreeg jij een draai om je oren omdat je oom een 13-jarige achter een root-console van de mainframe liet?

[active2]

Guru Evi schreef op 13 January 2003 @ 01:01:
killall is idd gevaarlijk om te gebruiken, net als ctrl-alt-del enzo
kill -9 <procesid> gebruiken is het beste eigenlijk
Ik weet nog toen ik 13 jaar was mocht ik met mijn nonkel mee naar zijn werk omdat daar veel pckes stonden (Unix mainframe's) en ik mocht ff tokkelen op een machien (had een schermpje, was ingelogd als root) en ik vond niet beter dan een killall te doen (en die Unix had ook nog auto-aanvulling: mijn nickname van toen: killah: do you mean killall (y/n) ) waarna het gehele bedrijf zo'n 15 minuten moest wachten om verder te werken. That was fun (totdat ik een tegen mijn oren kreeg)

LOL

Maar of ctrl-alt-del te gebruiken: Da's toch voor het rebooten van een machine??

* active2 heeft dat veranderd in zijn inittab: echo "Dat soort grappen haal je maar in windows uit!!!"

[Mark]

Verwijderd schreef op 12 januari 2003 @ 16:10:
//offtopic


[...]


2 woorden: Remote webconsole... Je gaat toch geen beheer op een HP-UX machine doen via een telefoonlijntje en dan geen remote webconsole hebben??

Tsjah, dat mag je tegen de tich klanten zeggen waarvoor ik het beheer doe op soortgelijke machines, over een investering van een paar honderd euro kunnen sommige bedrijven flink moeilijk doen tegenwoordig.

Het is gewoon zo dat je bepaalde commando's niet aan moet leren. Voordat je het weet heb je een probleem.

[Wilke]

[voorbeeld]
Je gaat nu ook je eigen grep proberen te killen. Je hoeft niet bang te zijn dat niet alle gewenste processen worden gekilled, want de grep is al afgelopen tegen de tijd dat er daadwerkelijk gekilled gaat worden (kill: 2241: no such process).

Dat is de vraag, is implementatie-afhankelijk volgens mij.

MAAR er zou in de tussentijd een ander proces met dit pid opgestart kunnen zijn dat je dan onbedoeld killed...

[/nohtml]

Kleine kans, maar het kan inderdaad.

De standaard-ranzige-oplossing om dit te voorkomen is altijd te doen 'grep [d]atwatjezoekt'. Dan krijg je het grep-proces zelf er niet bij (is korter/makkelijker dan nog een keer grep -v grep erover, en voorzover ik weet een altijd-werkende oplossing ).

Neemt niet weg dat ik het gewoon met je eens ben dat je het beter niet kunt gebruiken hoor...daar niet van