Prosesser som henger

Av og til hender det at en prosess (et program som utføres) «henger seg opp» på en datamaskin. Denne siden prøver å forklare hvordan dette kan unngås, og hva man kan gjøre hvis det skjer.

Best Viewed With Any Browser PNG now! Denne siden er laget for å kunne brukes av alle browsere. Du trenger imidlertid støtte for PNG for å kunne se på bildene.


Kanskje er du kommet til denne siden pga. en mail jeg har sendt deg. Jeg holder nemlig et øye med noen av instituttets Unix-maskiner, og sender av og til mail til folk som jeg mistenker har en prosess som «henger».

Holder øye med? Hvordan da?

Av og til sjekker jeg load på noen av instituttets datamaskiner (de jeg av og til bruker selv). Load er et slags mål på hvor mye en maskin har å gjøre. Programmet xload lager et stolpediagram av maskinens «load».

Bilde av xload-diagrammer
Figur 1

Figur 1 viser et eksempel, og her kan man se at maskinen marlene (min egen maskin) har lite å gjøre, load er jevnt over ganske lav. Dette er normalt for en maskin med bare én bruker, hvis jeg ikke kjører noen tunge programmer. Maskinene minelli og pckjemi63 gjør heller ikke så mye.

waage derimot, har en load på noe over 1, og har hatt det en stund. Det er helt naturlig at load fyker i været hvis noen f.eks. kjører latex eller gzip. Men hvis load holder seg stabilt over 1 (eller høyere) blir jeg mistenksom...

Ved å kjøre programmet top på den aktuelle maskinen får jeg en oversikt over hvem som gjør hva:

  load averages:  1.25,  1.65,  1.65                                   15:16:58
  231 processes: 2 running, 1 waiting, 54 sleeping, 173 idle, 1 stopped
  CPU states: 85.4% user,  0.0% nice, 14.5% system,  0.0% idle
  Memory: Real: 90M/183M act/tot  Virtual: 157M/351M use/tot  Free: 6800K
  
    PID USERNAME PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
   4779 NN        51    0 8976K    8K run   921:12 87.50% emacs
   1070 root      42    0 2624K  409K WAIT    2:37  6.60% smbd
  32127 hpv       44    0 3688K  679K run    13:14  1.20% top
    284 root      44    0 4032K 1974K sleep  33.0H  0.90% ypserv
  
(top avsluttes ved å taste q)

Først kommer det noen linjer med generelle opplysninger om maskinen (bl.a. load, i snitt over forskjellige tidsintervaller). Så kommer en liste over hvilke prosesser som kjører, sortert på CPU-tidsforbruk. Her kan man bl.a. se at jeg (hpv) kjører top og at root kjører ymse prosesser. Og man ser at NN kjører emacs, og at emacs bruker nesten 90% av CPU-tiden. Lar man nå top stå en stund vil man se at denne emacs'en faktisk bruker all den CPU-tiden som er tilgjengelig. Hvis jeg nå f.eks. kompilerer et program ser det kanskje slik ut:

    PID USERNAME PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
   4779 NN        50    0 8976K    8K run   929:37 39.20% emacs
   9721 hpv       50    0 5168K 1810K run     0:01 32.20% cc1
Her må kompilatoren (cc1) dele CPU-tiden med emacs'en, og kompileringen bruker derfor lengere tid enn den ellers ville gjort. Operativsystemet fordeler CPU-tid til de prosessene som ber om det, så et program som ber om mest mulig tid vil få andre prosesser til å gå tregere enn nødvendig. Unntak er prosesser som kjører med høy «nice»-verdi, ie. har et positivt tall i kolonnen for NICE, over. Dette er f.eks. tilfelle med dnetc, som jeg tidvis kjører på en del maskiner.

En prosess bruker også endel minne. Med top kan man se at emacs'en bruker 8976 kilobytes, men bare 8 av disse er «resident» i fysisk minne. Resten er «swappet ut» til disk. Man kan også se at emacs'en har gått i over 900 CPU-minutter, det er ganske mye for et slikt program.

Alt tyder på at denne emacs'en henger, og at den ikke gjør noe fornuftig. Så derfor er det i alles interesse at den blir «drept». Jeg har root-tilgang, så jeg kan strengt tatt drepe andres prosesser, men jeg vil helst ikke gjøre det: Jeg kan tross alt ta feil! Det er i slike situasjoner jeg kanskje sender en mail til NN og ber ham eller henne drepe den aktuelle prosessen.

Drepe hvem? Hvordan?

Å «drepe» en prosess vil si at man ber operativsystemet avslutte prosessen. I Unix er alle prosesser identifisert med et PID-nummer, dette finnes i første kolonne i utput'en fra top (over). PID til denne emacs'en er altså 4779. Kommandoen for å drepe emacs'en blir da:
  kill 4779
Mer presist sender man et signal til prosessen. Det finnes flere signaler, og hvis man ikke spesifiserer noe annet sender man signalet TERM (15), som vanligvis vil få prosessen til å avslutte på en pen og ryddig måte. Hvis dette ikke virker (sjekk med top eller ps) kan man prøve KILL-signalet (9):
  kill -KILL 4779
Dette vil (nesten) alltid drepe prosessen, brutalt og effektivt. Programmet vil ikke få anledning til å rydde opp etter seg.

Hva med isengard?

Godt spørsmål. Av figur 1 ser man at også isengard har load som ligger veldig stabilt på 1. Dette tyder på at at én eneste prosess jevnlig ber om CPU-tid, men at maskinen ellers ikke har så mye å gjøre. Å kjøre top på denne maskinen viser imidlertid ingen ting spesielt:
    PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
   4359 hpv       18   0   844  844   632 R       0  3.4  2.7   0:01 top
   1574 root       1   0   416  380   280 S       0  0.1  1.2   0:40 nmbd
      1 root       0   0   116   68    48 S       0  0.0  0.2   0:05 init
Jeg er ikke sikker, men gjetter på at noen f.eks. har en netscape gående med en liten animasjon eller noe slikt. Slikt krever litt CPU (og load telles opp), men vil ikke ta all den tiden som er tilgjengelig, og følgelig ikke sinke andre prosesser i særlig grad. Dette viser bare at load isolert sett er et dårlig mål på hvor belastet en maskin er.

Hvorfor blir en prosess hengende?

Jeg vet ikke sikkert. Men jeg har intrykk av at det ofte skjer hvis man ikke avslutter programmet på den «riktige» måten. Tekstprogrammer som pine, latex og ftp ser ut til å kunne henge hvis man bare logger seg ut (kobler ned forbindelsen) uten å avslutte programmet.

I X vil vindow-manager'en din tilby menyvalg for å «lukke» vinduer. Med kjemisk institutt's «standardoppsett» får du fram denne menyen bl.a. ved å klikke med musa i firkanten øverst til venstre i vindus-ramma, som vist i figur 2:

Meny fra fvwm, med «standardoppsettet»
Figur 2

Desverre virker ikke dette alltid like bra, og å lukke vinder på denne måten vil ikke alltid medføre at programmet avsluttes. Tvert imot kan det føre til at programmet henger.

Dette er en liten liste over noen av de programmene jeg har sett har vært hengende, og (for de programmene jeg kjenner) anbefalte måter å avslutte dem på:

Mange programmer kan også drepes ved å trykke C-c (kontroll-C) i det vinduet programmet ble startet (dette tilsvarer vanligvis å sende et TERM-signal). Hvis programmet ikke lar seg avslutte på noen «skikkelig» måte kan du sende et KILL-signal som beskrevet over. Hvis du ikke finner PID'en med top kan du prøve kommandoen ps ux eller ps -u mitt_brukernavn.

Hvorfor mase om dette?

Det er riktig at dette ikke har allverdens betydning. Maskinen går ikke i stykker av å jobbe litt, og de forsinkelsene én enkelt hengende prosess medfører kan knapt merkes for den vanlige bruker. Men hvis man ikke rydder opp i hengende prosesser blir det etterhvert gjerne fler av dem, og jo flere prosesser skal dele på CPU-tiden, jo tregere vil det gå for den enkelte. En maskin som waage har mange brukere og ellers mye å gjøre, og det er derfor en fordel om alle samarbeider om å la ting gå glattest mulig.

Mange er helt ukjente med dette problemet inntil jeg sender dem mail. Derfor har jeg satt sammen denne siden, så jeg skal slippe å forklare tingene om igjen for hver mail.

Det kan selvsagt hende at jeg har tatt feil i mine antagelser, at prosessen din slettes ikke henger, men derimot gjør noe nyttig eller morsomt. I så tilfelle kan du selvsagt se bort fra min henvendelse, og jeg beklager at jeg «maste». Men husk at en maskin som waage har mange interaktive brukere, så hvis du ofte kjører tunge beregninger o.a. bør du vurdere å heller kjøre disse om natten, eller bruke klynga eller en annen mer dedikert maskin.

Hvor kan jeg finne ut mer?

Manualsidene for top(1), ps(1), kill(1) og nice(1) er greie steder å begynne hvis du vil vite mer om disse kommandoene, mens signal(7) forteller mer om signaler. Tallet i parentes er seksjonen i manualen, du kan spesifisere dette som f.eks. man 7 signal, til forskjell fra signal(2).
Lykke til med ditt videre arbeid på datamaskinene! Har du noe å tilføye eller kommentarer? Send meg gjerne en mail!
Email address: Spam protection, download image to read address.