ubuntuuser42 skrev:lath skrev:ubuntuuser42 skrev:... og så er der faktisk også nohup kommandoen
http://en.m.wikipedia.org/wiki/Nohup Men at blokere for hang up signalet kan godt give uønskede 'sidegevinster' når programmet nægter at dø.
Det er ikke et problem, for så sender du bare programmet et SIGKILL signal, som det ikke kan undslippe døden fra.
Hvis programmet process id (PID) er , feks. 1234 dræber den her kommando programmet med PID=1234:
Er det firefox der guru mediterer og den ikke reagerer kan du få firefox til at dø ved at trække firefox PIDs ud med pgrep og overføre dem til kill kommandoen som argumenter på den her måde:
/Lars
Uenig. 'kill -9' er ikke en løsning på ovenstånde, det er en grim workaround når man ikke kan andet. Grunden er at programmet man rammer ikke får chancen for at lægge sig pænt ned. F.eks. er en kill -9 på firefox eller andre risikabel idet programmet ikke får ryddet ordentlig op (har betalt mine dyre lærepenge i flere omgange...)
Hvis programmet er kommet i en udefineret tilstand er det kun programmørens skyld og ingen andre. Punktum!
Programmer må aldrig komme ud i en udefineret tilstand, fordi at det er i udefinerede tilstande at programmet enten:
- delvis virker, uden at ødelægge brugerens data (føl dig heldig)
- programmet bare ikke virker - det er stendødt
- programmet giver garbage ud, det er en variant af at data ødelægges
- programmet crasher Programmet bliver brutalt lukket ned af kernen (en kill SIGKILL køres mod programmet - inde fra kernen), fordi det forsøger at tilgå hukommelse der ikke er programmets ejendom
- programmet ødelægger brugerens data, så programmet i den definerede tilstand ikke kan læse brugerens data (dårligst)
Deadlock og livelocks er udefinerede tilstande, hvor en kill SIGKILL er eneste løsning, da man ikke kan reparere på deadlocks og livelocks på et kørende program.
At programmet (her firefox) ikke får ryddet pænt op er bare dårlig programmering, så må man skille programmet i en baggrundsproces, der er en service der styrer brugerens data, og en forgrundsproces, som ofte er den der indeholder de fleste fejl.
Chrome browseren har vist vejen ved at bruge flere processer, som giver en mere stabil browser. Hver tilføjelse kører endda i sin egen proces, altså som et program.
BTW, min favoritbrowser er Firefox, men jeg bruger også Chrome til nogle websides som firefox er dårlig til at håndtere, f.eks. Twitter.
/Lars
Jeg er Software ingeniør (Diplomingeniør) i Informationsteknologi og
indlejede systemer, hvor indlejrede systemer
er computer (microcontroller) + elektronik i for eksempel et TV, en router, en vaskemaskine og den slags