Newsgroup: it.comp.os.linux.iniziare
Titolo: Uccidere un processo immortale.

Preciso che son su Mac con macOS 10.14, ma sul gruppo dedicato ormai non
c'è quasi nessuno che abbia qualche nozione su quel che sta sotto la
GUI.
Avrei bisogno di sapere come chiudere un processo (Atom) che mi è
restato appeso e che non reagisce a nessun comando kill o killall (anche
come root). Il processo si vede ancora sia sulla GUI sia con i vari
comandi top/ps. Con la GUI il processo si chiude men che meno.
C'è qualcosa che posso provare prima del tentativo estremo di un 'sudo
reboot -n' (The file system cache is not flushed.  This option should
probably not be used). Sono convinto che con un riavvio normale mi
appenderebbe anche il Mac, l'unica opzione che conosco è quella sopra,
ma preferirei trovare il modo di chiudere il processo e poi riavviare
normalmente.
 
-- 
Per contattarmi, togliere -NOSPAM- dall'indirizzo.
To contact me, remove -NOSPAM- from address.

 come root).
 
Se vuoi assolutamente killarlo il comando pero' e':
#: kill -9 numero_tuo_processo
 
col -9 penso sia impossibile che non lo chiuda ciao ma bada: non ti
garantisco nulla eh, fai tutto a tuo rischio t'ho solo detto quel
che ricordo
 
-- 
Yoda
 


 
Hai provato con
# kill -9 pid_del_processo
oppure
# kill -KILL pid_del_processo
se sono supportati i nomi?
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 #: kill -9 numero_tuo_processo
 
Sě, provato (anche sudato) ma non gli ha fatto un baffo.
Alla fine un po' alla volta si č bloccato tutto il sistema, e ho dovuto
usare un reset hardware (non rispondeva piů neppure il terminale :-(


 usare un reset hardware (non rispondeva più neppure il terminale :-(
 
Allora la prossima volta se per jella dovesse ricapitarti butta un
occhio alle sysrq, pero' da terminale non so, io sto in console a
caratteri.. cosa impossibile credo per il tuo Mac.
Comunque eccole ciao
 
-cite-
0..9 imposta il livello di log della console, livello che decide
il tipo di messaggi del kernel che devono essere inviati alla
console
 
b riavvio immediato del sistema, senza smontare le partizioni o
sincronizzare i dischi
 
c riavvia kexec e produce un dump di sistema che contiene
informazioni sul blocco avvenuto
 
e invia il segnale SIGTERM a tutti i processi eccetto init (PID1)
 
f invoca oom_kill, il quale termina il processo che sta causando
un eccessivo consumo di memoria, salvando il sistema da un
possibile stato di memoria esaurita
 
h mostra nella console un documento di aiuto (valido per ogni
altra lettera non assegnata ad un comando)
 
i invia il segnale SIGKILL a tutti i processi eccetto init (PID1)
 
k termina tutti i processi nell'attuale console virtuale in modo
forzato (kill). Può essere usato ad esempio per terminare la
sessione grafica (server X). Questo uso è stato originariamente
introdotto per imitare un tasto di accesso sicuro (Secure Access
Key) intercettabile solo dal kernel
 
l invia il segnale SIGKILL a tutti i processi, compreso init (PID1)
 
m mostra nella console le informazioni attuali sulla memoria
 
o spegne completamente il sistema
 
p invia alla console le informazioni sui registri e le flag
attuali
 
r passa la tastiera dalla modalità raw, quella utilizzata da
programmi come X11 e svgalib, alla modalità XLATE
 
s sincronizza i filesystem montati
 
t mostra nella console una lista dei processi attuali con le
relative informazioni
 
u rimontare tutti i filesystem montati in modalità di sola
lettura
 
v mostra le informazioni sul processore SMP Voyager
 
Questi alcuni tra i tasti più utili:
b – Riavvia immediatamente il sistema senza sincronizzare o smontare i dischi
o – Spenge immediatamente il sistema (se configurato e supportato)
s – Cerca di fare sync su tutti i filesystem montati
u – Cerca di rimontare tutti i filesystem montati read-only
p – Fa il dump dei registri e flags e la stampa sulla console
t – Fa il dump dei task correnti e stampa le informazioni relative in console
m – Fa il dump della memoria e lo stampa in console
e – Invia un SIGTERM a tutti i processi, tranne init.
i – Invia un SIGKILL a tutti i processi, tranne init.
l – Invia un SIGKILL a tutti i processi, INCLUSO init.
-/cite-
 
-- 
Yoda
 

 normalmente.
 
Da ingorantone della mela, farei così:
- man kill
- man killall
 
E cercherei tra le opzioni se ci sono le equivalenti di -9,
vedi “man 7 kill”. Comunqe il 9 sta per SIGKILL che in pratica
“uccide” il processo.
 
Puoi fare una prova al volo:
 
kill -9 <numero-processo>
 
oppure
 
killall -9 <nome-processo>
 
Ad ogni modo sembra un bug noto:
https://github.com/atom/atom/issues/17672
 
 
ps -ef | grep [Aa]tom
 
e poi vai di kill -9.
 
Su linux c’è anche il comando pgrep per cercare il processo
tipo: pgrep Atom, o pgrep -a atom, o meglio pgrep -ia atom
perché è case sensitive. E il suo compago pkill con cui puoi
uccidere tutti i processi il cui nome corrisponde ad un certo
pattern. Utile se hai tanti processi appesi e vuoi terminarli
tutti in una volta, ovviamente se hanno lo stesso nome o simile:
prima è sempre saggio andare di pgrep e poi una volta che si
sa quali processi saltano fuori, si può dare il colpo di grazia
con pkill...

 caratteri.. cosa impossibile credo per il tuo Mac.
 
Io credo sysrq sia *solo* ed *esclusivamente*
una cosa del kernel Linux, che non mi risulta
sia in MacOS, bensi` BSD.
 
bye,
 
-- 
 
piergiorgio

 usare un reset hardware (non rispondeva più neppure il terminale :-(
 
Una volta questo succedeva quando un
processo era in attesa di qualcosa,
tipicamente I/O.
 
Dato che non era in esecuzione, non
poteva essere eliminato.
 
Credo MacOS sia BSD, ma credo anche
questo non debba succedere.
 
Molto probabilmente un qualche bug
incrociato tra kernel e processo.
 
bye,
 
-- 
 
piergiorgio

 
https://github.com/atom/atom/issues/17672
 
Il problema sembra diverso, perché qui dicono che capita di frequente ma
si risolve forzando la chiusura. A me è capitato una volta, ma non c'è
stato verso di chiudere Atom, che si è trascinato dietro l'intero
sistema (non so se ha fatto da solo, o se hanno contribuito i miei
tentativi di schidarlo).


 questo non debba succedere.
In liena di massima sì, sotto macOS gira un BSD customizzato. Tante cose
non dovrebbero succedere, ma succedono. Comunque adesso che mi ci fai
pensare, potrebbe essere che Atom fosse aperto quando ho spostato
l'applicazione dalla scrivania alla cartella delle Applicazioni:
probabilmente è questo che ha causato il blocco. Anche se lo spostamento
lo avevo fatto almeno un oretta prima che si bloccasse... comunque ci
può stare.
Quello che, come di ci tu, non dovrebbe succedere, è che si tiri dietro
il sistema e che non ci sia modo di killare il processo.


 usare un reset hardware (non rispondeva più neppure il terminale :-(
 
evidentemente si era rotto qualcosa a basso livello nella gui, se è vero 
che alla fine non rispondeva più. se un processo user non risponde alla 
kill vuol dire che il kernel ha qualcosa da ridire e si rifiuta di 
eseguire.
non credo sia riproducibile, probabilmente il sistema era in uno stato 
non stabile per chissà quale motivo.

 tentativi di schidarlo).
 
Sei sicuro che non si sia chiuso e si sia poi “rigenerato”?
E che quindi ti sembra lo stesso processo di prima perché
ha lo stesso nome, ma in realtà è un altro nuovo?
Questo potresti saperlo o verificarlo dal PID, cioè dal numero
del processo, se dopo il kill cambia allora qualcosa non torna
ed è indice che il programma è stato riavviato in qualche modo
quando tu lo hai terminato con kill.
A volte è capitato anche a me che alcuni processi non si terminassero
con kill <pid>, ma che invece funzionasse kill -9 <pid>, evidentemnte
non è il tuo caso.

 
 
Credo non ci sia molto da cercare...
 
Il Sistema è andato in bomba (come si dice con i Mac).
 
Amen
 
Ogni tanto capita.

 Il Sistema è andato in bomba (come si dice con i Mac).
Si diceva ai tempi di Mac OS 9 e precedenti. Con Mac OS X si è passati
ai "Kernel Panic". Piuttosto rari, comunque. ;-)


 reboot -n'
 
Hai provato tagliandogli la testa? Occhio che la riminiscenza potrebbe essere
traumatica
 
Enrico

 
 
Il "Kernel Panic" si verifica quando vedi la tendina grigia per poi far 
comparire le scritte in coreano...
 
In effetti è ormai abbastanza raro.
 
Quando qualche cosa non va come deve andare il sistema si pianta e basta.