slacky.eu

salve,
non so come mai ma non riesco a buttare giù un demone che mi sta prendendo troppe risorse...
sono loggato come utente ma apro un terminale digito "su" poi "top" guardo il PID e poi faccio ma se rifaccio "top" il demone è sempre lì... come mai?
mi tocca riavviare il pc... uff!

smtux ha scritto:salve,
non so come mai ma non riesco a buttare giù un demone che mi sta prendendo troppe risorse...
sono loggato come utente ma apro un terminale digito "su" poi "top" guardo il PID e poi faccio

Codice: Seleziona tutto

kill PID

ma se rifaccio "top" il demone è sempre lì... come mai?
mi tocca riavviare il pc... uff!

proca con kill -9

esatto. kill di default invia SIGTERM (terminate), che alcune applicazioni intercettano e agiscono in modo diverso dalla terminazione. SIGKILL invece non può essere intercettato, e causa sempre la terminazione dell'applicazione. se non termina nemmeno con sigkill hai trovato un bug nel kernel .

useless ha scritto:esatto. kill di default invia SIGTERM (terminate), che alcune applicazioni intercettano e agiscono in modo diverso dalla terminazione. SIGKILL invece non può essere intercettato, e causa sempre la terminazione dell'applicazione. se non termina nemmeno con sigkill hai trovato un bug nel kernel .

questo non e' esatto, non necessariamente un processo e' killabile con SIGKILL e se non si killa non e' detto che sia un bug del kernel; un esempio puo' essere un processo in uninterruptible sleep (status D su ps), che non e' killabile in alcun modo.

ah sì? e come fa un processo a finire in quello stato?

useless ha scritto:ah sì? e come fa un processo a finire in quello stato?

spesso accade durante le operazioni di i/o; ad esempio se stai facendo operazioni di lettura/scrittura su un fs montato via nfs e il server nfs non risponde piu', il processo che stava facendo quelle operazioni e' facile che vada in uninterruptible sleep e non sia killabile.

ahhhh! ora capisco tante cose! grazie della correzione .

comunque, x ricapitolare x i "meno tecnici": se un processo è killabile, SIGKILL lo killa sicuro.

masalapianta ha scritto:se stai facendo operazioni di lettura/scrittura su un fs montato via nfs e il server nfs non risponde piu', il processo che stava facendo quelle operazioni e' facile che vada in uninterruptible sleep e non sia killabile.

e in questo caso qual e' la soluzione? a me capitava una cosa del genere quando usavo un hard disk "morente" in un box usb.

Supponiamo che un demone possa essere ucciso con la pressione di CTRL+C che equivale al segnale SIGINT.
Se non conosco il suo PID come faccio?

smtux ha scritto:Supponiamo che un demone possa essere ucciso con la pressione di CTRL+C che equivale al segnale SIGINT.
Se non conosco il suo PID come faccio?

Codice: Seleziona tutto

kill -s SIGINT nome_demone

non bisognerebbe usare killall -int nome_demone?

ps aux | grep nome
la seconda colonna è il pid, e poi lo killi. se vuoi killarlo x nome puoi usare pkill o killall.

come lo vedete?