Kent Friis wrote:
>
> Det kan også være den er stoppet fordi
> den venter på at komme af med noget output, enten fordi den kører på
> en langsom terminal (seriel terminal), eller fordi nogen har trykket
> på Ctrl-S eller Scroll-lock.
Nej, det er ikke rigtigt. I de tilfælde du beskriver
vil processen blocke på en skrivning, men den vil
ikke blive suspenderet.
De tilfælde hvor en terminal kan suspendere en process
er hvis der trykkes Ctrl+Z eller hvis en baggrundsprocess
prøver at lave I/O til en terminal, der ikke tillader
baggrunds I/O. (Jeg mener default er at tillade
baggrundsprocesser at skrive til terminalen men ikke
læse).
Hvis den stoppede process er underlagt en shells
jobkontrol, så finder man den shell og beder om at få
processen startet igen.
Man skriver jobs for at få en liste over jobs i den
pågældende shell, og så kan man skrive fg %jobnummer
(kan forkortes til %jobnummer) eller bg %jobnummer
(kan forkortes til %jobnummer &) for at starte hhv
i forgrunden og baggrunden. Starter du den i
baggrunden risikerer du selvfølgelig, at den bliver
stoppet med det samme igen.
Eksempel:
[kasperd@hactar:pts/18
] jobs
[1]- Stopped xclock
[2]+ Stopped xload
[kasperd@hactar:pts/18
] %2 &
[2]+ xload &
[kasperd@hactar:pts/18
] %1
xclock
Hvis den stoppede process ikke er underlagt nogen
shells jobkontrol, så kan den startes igen med kill
kommandoen. Til det formål anvendes CONT signalet.
F.eks. kill -CONT 10062
--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.