Elk programma wat op de computer draait is een proces. En elk proces heeft een eigen unieke ID. Dat wordt een PID genoemd. Normaal gesproken heb je daar niets mee te maken. Maar het kan interessant worden als je wilt weten hoeveel processorkracht een bepaald proces gebruikt. Of wanneer je een lopend proces wilt beëindigen.
Nee, dit is geen post scriptum onder aan een brief. Met ps kun je een lijst opvragen van alle processen die momenteel op je computer lopen.
ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 1.2 9740 5992 ? Ss Nov17 2:11 /sbin/init root 2 0.0 0.0 0 0 ? S Nov17 0:02 [kthreadd] root 4 0.0 0.0 0 0 ? I< Nov17 0:00 [kworker/0:0H] root 6 0.0 0.0 0 0 ? I< Nov17 0:00 [mm_percpu_wq] root 7 0.0 0.0 0 0 ? S Nov17 4:33 [ksoftirqd/0] root 8 0.0 0.0 0 0 ? S Nov17 0:00 [kdevtmpfs] root 9 0.0 0.0 0 0 ? I< Nov17 0:00 [netns] root 11 0.0 0.0 0 0 ? S Nov17 0:03 [khungtaskd] root 12 0.0 0.0 0 0 ? S Nov17 0:00 [oom_reaper]
Dit zijn de eerste 10 processes op mijn Raspberry Pi.
Je ziet dat deze allemaal door de gebruiker root gestart zijn.
Daarnaast komt de PID kolom.
PID 1 is speciaal, dat is het eerste proces wat gestart wordt wanneer het systeem wordt opgestart.
Als je dat proces sluit zal het hele systeem stoppen met werken.
Daarna volgen de kolommen met het CPU gebruik, geheugengebruik, virtueel geheugengebruik, swap geheugengebruik, gekoppelde terminal, status, starttijd van het proces, en ten slotte het commando wat dit proces startte.
Je hoeft niet te snappen wat al deze kolommen betekenen.
De belangrijkst zijn de gebruiker, de PID, de starttijd en het commando.
Met die informatie kun je bepaalde processen identificeren.
Laten we maar weer eens een heel langdurig achtergrondproces starten en dan kijken of we dat kunnen vinden:
sleep 10000 & [1] 7002 ps aux | grep sleep pi 7002 0.0 0.2 3460 1372 pts/0 S 19:44 0:00 sleep 100000 pi 7004 0.0 0.3 4364 1756 pts/0 S+ 19:44 0:00 grep --color=auto sleep
Jammer, zodra we het sleep commando in de achtergrond starten verklapt het systeem het PID nummer al.
In ons voorbeeld is dat 7002, maar dat is bij jou vast een ander getal.
Het ps commando bevestigt dat het PID nummer inderdaad 7002 is.
En je ziet dat het commando klopt, en de starttijd moet overeenkomen met de tijd waarop je het proces startte.
De tweede regel, met PID 7004 is het proces van het grep commando zelf.
Die mogen we negeren.
Sterker nog, zodra je de output op je scherm ziet is dat proces al weer gestopt.
We zien in ons voorbeeld dat de processor niet belast wordt door ons sleep commando. Maar stel nu dat we het sleep commando vroegtijdig willen stoppen.
kill 7002 [1]+ Terminated sleep 100000
Dat klinkt drastisch, we doden het proces.
Maar wat kill eigenlijk doet is een signaal sturen naar een proces.
Een proces hoort op zo’n signaal te reageren.
Er zijn vele verschillende signalen die je naar processen kunt sturen.
Standaard is dat het SIGTERM signaal.
Hiermee vraagt het systeem beleefd aan een proces om te stoppen waar het mee bezig is, en eventueel wat rommel netjes op te ruimen.
Een proces hoort daar braaf op te reageren.
In ons geval deed ons sleep proces netjes wat er gevraagd werd.
Maar wat nu als het proces, om wat voor reden dan ook er niet in slaagt om netjes te stoppen?
Het proces wacht bijvoorbeeld op een disk om zijn data netjes op te kunnen slaan, terwijl de disk niet meer beschikbaar is.
Zo’n proces blijft dan eindeloos wachten.
Dan kun je ook het SIGKILL signaal sturen.
Dat signaal staat bekend als kill -9.
Met dat signaal moet een proces hoe dan ook stoppen, er wordt niet eens verwacht dat het process zijn rommel netjes opruimt, met als gevaar dat er data verloren kan gaan.
Er zijn nog talloze andere signalen, die je zelden of nooit hoeft te sturen.
Wat je wel eens tegen zou kunnen komen is SIGHUP signaal, wat er voor zorgt dat een proces zijn configuratiebestand opnieuw inleest.
Hiermee kun je de configuratie van een service (daemon) aanpassen, zonder die service opnieuw te moeten starten.
Let wel dat processen alleen verplicht zijn om op de SIGTERM en SIGKILL signalen te reageren.
Andere signalen zijn optioneel.
Je mag natuurlijk alleen signalen sturen naar processen die ook werkelijk van jou zijn.
Je mag dus geen proces van een ander killen.
Tenzij dat je natuurlijk de root gebruiker bent, want die mag alles.
Dus het kan dus zijn dat je het sudo commando nog voor het kill commando moet plaatsen.
Soms heb je wat meer haast om een op hol geslagen proces te stoppen. Dan kun je gebruikmaken van het killall commando.
sleep 10000 & [1] 7130 sleep 5000 & [2] 7131 sleep 7000 & [3] 7132 killall sleep [1] Terminated sleep 10000 [2]- Terminated sleep 5000 [3]+ Terminated sleep 7000
Zoals je ziet worden meteen alle sleep processen gestopt.
Deze hoort hier eigenlijk niet, maar ik wil hem toch even noemen.
Met xkill kun je snel een venster in je grafische interface killen.
Maar dat kan dus alleen met processen (vensters) in je eigen computer.
Dat gaat dus niet lukken wanneer je een programma op een op afstand bestuurde computer wilt killen.
En ook processen zonder venster kun je hier niet mee killen.
Nadat je het xkill commando hebt gegeven verandert je muiscursor in een kruisje.
Vroeger was dat een doodshoofd overigens.
Door dat kruisje nu ergens in een venster te klikken zal dat betreffende venster meteen afsluiten.
Het top commando toont een lijst met lopende processen.
Deze lijst wordt steeds ververst.
Standaard staan de processen die de meeste processorcapaciteit verbruiken bovenaan in de lijst.
En ook hier kun je aan de PID en het commando zien welke processen het allemaal zijn.
Dit kan interessant zijn wanneer je op zoek bent naar een proces wat je hele systeem op slot dreigt te gooien.
Met q stop je het top commando.
Dit was slechts een zeer beknopte uitleg van het top commando.
Er is nog een betere versie van top, htop, wat nog meer informatie over lopende processen geeft en waarbij je rechtstreeks commando’s kunt geven, zoals het killen van bepaalde processen.
Maar dat is stof voor een heel nieuw hoofdstuk.