Re: Processo immortale
On 06/10/2018 00:27, Felipe Salvador wrote: Dunque il processo oltre a rimenere in uno stato in cui e' impossibile ucciderlo in teoria lo puoi far terminare in ogni caso usando gdb. Avevo indicato un metodo semplice nella mia risposta, però non so se funziona in questo caso. Poi in teoria, se si è capaci per l'architettura hardware su cui sta girando, è possibile modificare l'esecuzione dal punto in cui si trova ora. Solo che se il problema sono i socket che non sono chiusi correttamente, allora l'errore si ripresenta subito... Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Client di posta: http://www.mozilla.org/products/thunderbird GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Processo immortale
On Thu, Oct 04, 2018 at 08:15:33AM +0200, Piviul wrote: > Il 03/10/18 18:44, Felipe Salvador ha scritto: > > [...] > > Posto che questo non e' il tuo problema, mi sembra di capire che la > > tua priorità' e' uccidere quel processo, avete considerato il restart di > > apache? > ha già specificato che apache non c'entra nulla, è uno script lanciato > in cron. Noto ora, da php-cli[¹]. E' presente unstable ma non in stretch. Non ho nessuna difficoltà a riconoscere l'analisi di Davide come valida, anzi. Espongo dubbi non certezze. Dunque il processo oltre a rimenere in uno stato in cui e' impossibile ucciderlo e' rimasto orfano, io penso che questo sia l'effetto del SIGKILL. Lo scrivo qui, anche se quanto scrivo potrebbe gia' essere stato eseguito: E' generalmente piu appropriato inviare SIGTERM quando si cerca di chiudere un processo. Questo comunque non significa che con SIGTERM avreste certamente risolto. Può provare, se non lo ha già fatto, ad inviare altri segnali. SIGUSR1 (ce ne sono tre, credo -10) ad esempio, che causa (almeno per bash) un errore del processo e la successiva uscita. SIGHUP, etc etc. [¹] https://secure.php.net/manual/en/features.commandline.io-streams.php > Piviul -- Felipe Salvador
Re: Processo immortale
Il 03/10/18 18:44, Felipe Salvador ha scritto: [...] Posto che questo non e' il tuo problema, mi sembra di capire che la tua priorità' e' uccidere quel processo, avete considerato il restart di apache? ha già specificato che apache non c'entra nulla, è uno script lanciato in cron. Piviul
Re: Processo immortale
On 02/10/2018 23:46, Felipe Salvador wrote: On Tue, Oct 02, 2018 at 09:04:09PM +0200, Davide Prina wrote: * un bug hardware * un bug di Linux Però penso che gli ultimi due casi dovrebbero porre il processo nello stato D. Forse Z o X dopo tutti i kill che ha dato, fosse stato D sarebbe stato nella condizione che descrivi sopra, R dovrebbe essere regolarmente "killabile": ma, secondo me, se è un problema hardware o un bug di Linux dovrebbe finire in un'attesa infinita e quindi assumere lo stato D. Per questo che dicevo che secondo me non è uno di questi due problemi. Poi può essere che mi sbagli, anche perché in questi casi potrebbe succedere di tutto. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Petizione contro il formato ms-ooxml: http://www.noooxml.org/petition Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Processo immortale
On Wed, Oct 03, 2018 at 07:44:04AM +0200, Paolo Nicorelli wrote:
> On Tue, 2 Oct 2018 at 23:47, Felipe Salvador
> wrote:
>
> > Forse Z o X dopo tutti i kill che ha dato, fosse stato D sarebbe stato
> > nella condizione che descrivi sopra, R dovrebbe essere regolarmente
> > "killabile":
> >
> >Duninterruptible sleep (usually IO)
> >Rrunning or runnable (on run queue)
> >Sinterruptible sleep (waiting for an event to complete)
> >Tstopped by job control signal
> >tstopped by debugger during the tracing
> >Wpaging (not valid since the 2.6.xx kernel)
> >Xdead (should never be seen)
> >Zdefunct ("zombie") process, terminated but not reaped
> > by its parent
> >
> >
> > Sarebbe interessante vedere il contenuto dello script
> >
>
> E' in stato R, dal 21 agosto. A meno che `ps` non menta :P
>
> e guardando cosa combina con `strace` non esce nulla quindi l'ipotesi
> che sia una syscall che appesa è verosimile.
Fosse in stato R dal 12 dicembre 1984 non cambierebbe nulla, anche
nell'output di lsof non c'e' riferimento a file system di rete, ne a
situazioni di I/O che potrebbero giustificare quello stato.
Non essendo quel processo in stato di uninterruptible sleep non pensi
che manchino i presupposti per una 'syscall che appesa'?
https://eklitzke.org/uninterruptible-sleep
"can't identify protocol"
C'e' molto materiale in rete pe questo messaggio riportato da lsof,
anche sui canali relativi al PHP. Per la maggior parte sono altri
casi, ma in alcuni si parla di errori di programmazione.
https://secure.php.net/manual/en/function.socket-create.php
Posto che questo non e' il tuo problema, mi sembra di capire che la
tua priorità' e' uccidere quel processo, avete considerato il restart di apache?
> Per il contenuto dello script mi spiace ma non posso mostrarlo perchè non
> ne ho l'accesso neanche io.
> Gira su una macchina in produzione per $FamosaMultinazionale dove un'amica
> fa consulenza con la maglietta di $GrandeAziendaDiConsulenza e
> non credo sia appropriato (tanto più che non è codice suo ed io non
> collaboro con nessuno degli attori).
>
> So solo che:
> - c'è un qualcosa che controlla che non sia già attivo
> - sincronizza dei dati attraverso SOAP o sFTP
> - gira da CLI con cron (niente apache)
> - e su una macchina con altre decine di processi di sincronizzazione
> - per fare il reboot devi fare una mail con troppi destinatari
>
> Mi incuriosiva che un SIGKILL da root non facesse nulla... proprio perchè,
> come dici tu, R "dovrebbe" essere killabile.
--
Felipe Salvador
Re: Processo immortale
On Tue, 2 Oct 2018 at 23:47, Felipe Salvador
wrote:
> Forse Z o X dopo tutti i kill che ha dato, fosse stato D sarebbe stato
> nella condizione che descrivi sopra, R dovrebbe essere regolarmente
> "killabile":
>
>Duninterruptible sleep (usually IO)
>Rrunning or runnable (on run queue)
>Sinterruptible sleep (waiting for an event to complete)
>Tstopped by job control signal
>tstopped by debugger during the tracing
>Wpaging (not valid since the 2.6.xx kernel)
>Xdead (should never be seen)
>Zdefunct ("zombie") process, terminated but not reaped
> by its parent
>
>
> Sarebbe interessante vedere il contenuto dello script
>
E' in stato R, dal 21 agosto. A meno che `ps` non menta :P
e guardando cosa combina con `strace` non esce nulla quindi l'ipotesi
che sia una syscall che appesa è verosimile.
Per il contenuto dello script mi spiace ma non posso mostrarlo perchè non
ne ho l'accesso neanche io.
Gira su una macchina in produzione per $FamosaMultinazionale dove un'amica
fa consulenza con la maglietta di $GrandeAziendaDiConsulenza e
non credo sia appropriato (tanto più che non è codice suo ed io non
collaboro con nessuno degli attori).
So solo che:
- c'è un qualcosa che controlla che non sia già attivo
- sincronizza dei dati attraverso SOAP o sFTP
- gira da CLI con cron (niente apache)
- e su una macchina con altre decine di processi di sincronizzazione
- per fare il reboot devi fare una mail con troppi destinatari
Mi incuriosiva che un SIGKILL da root non facesse nulla... proprio perchè,
come dici tu, R "dovrebbe" essere killabile.
Re: Processo immortale
On Tue, Oct 02, 2018 at 09:04:09PM +0200, Davide Prina wrote:
> On 02/10/2018 09:19, Paolo Nicorelli wrote:
>
> > C'è il processo utente con PID 9583 che gira dal 21 Agosto.
>
> > kill -9 e sudo kill -9 non danno errori ma il processo rimane li
> > Non è zombie, è in stato R
> > pstree dice che il padre è init.
>
> il comando kill -9 lancia una chiamata asincrona per l'uccisione del
> processo indicato, se però il processo sta eseguendo una system call,
> allora questa può bloccare SIGKILL fino al suo completamento.
>
> Una system call può non terminare o impiegare tempi anche biblici per
> diversi motivi, ad esempio:
> * si sta cercando di accedere ad una risorsa (solitamente remota) che
> non è disponibile (es: un file system NFS) [in questo caso dovrebbe
> bastare rendere disponibile la risorsa, es: montare il file system
> NFS]
> * un bug hardware
> * un bug di Linux
>
> Però penso che gli ultimi due casi dovrebbero porre il processo nello
> stato D.
Forse Z o X dopo tutti i kill che ha dato, fosse stato D sarebbe stato
nella condizione che descrivi sopra, R dovrebbe essere regolarmente "killabile":
Duninterruptible sleep (usually IO)
Rrunning or runnable (on run queue)
Sinterruptible sleep (waiting for an event to complete)
Tstopped by job control signal
tstopped by debugger during the tracing
Wpaging (not valid since the 2.6.xx kernel)
Xdead (should never be seen)
Zdefunct ("zombie") process, terminated but not reaped by
its parent
Sarebbe interessante vedere il contenuto dello script
> Visto che il tuo processo è nello stato di running R dovresti capire
> cosa sta aspettando per risvegliarlo dallo sleep.
>
> Per individuare cosa sta aspettando si può provare in diversi modi:
> * cat /proc/PID/syscall
> * lsof -p PID (come ti hanno già suggerito)
> * strace -p PID
> * gdb PERCORSO_ALL'ESEGUBILE PID
>
> Guardando quanto hai postato per lsof
> > php 9583 userXXX 3u sock 0,8 0t0 485569960 can't identify protocol
> > php 9583 userXXX 5u sock 0,8 0t0 485583014 can't identify protocol
>
> direi che il problema potrebbe essere causato da questi due.
> Potrebbero essere dei socket che non sono stati chiusi correttamente
>
> dovresti vederli in stato CLOSE_WAIT anche eseguendo questo:
> # netstat -putan
>
> Però:
> 1) non so se è possibile terminare dei socket in quello stato... se
> non uccidendo il processo che li ha generati :-(
>
> 2) se il problema è questo, secondo me, l'unica è correggere il
> sorgente dove vengono aperti e farglieli chiudere correttamente... e a
> questo punto non so se puoi sostituire l'eseguibile (può essere uno
> script)
>
> Provare ad ucciderlo con gdb:
> gdb -p PID
> > kill
> Kill the program being debugged? (y or n) y
> > quit
>
> Se non funziona neanche così, dopo aver fatto il punto 2 devi
> riavviare la macchina... o far si che il processo abbia un altro nome
> (in modo che possa partire) e lasciare quello attivo in sleep.
>
> Ciao
> Davide
>
> --
> Dizionari: http://linguistico.sourceforge.net/wiki
> Petizione contro il formato ms-ooxml:
> http://www.noooxml.org/petition
> Non autorizzo la memorizzazione del mio indirizzo su outlook
--
Felipe Salvador
Re: Processo immortale
On Tue, 2 Oct 2018 at 21:04, Davide Prina wrote: > > il comando kill -9 lancia una chiamata asincrona per l'uccisione del > processo indicato, se però il processo sta eseguendo una system call, > allora questa può bloccare SIGKILL fino al suo completamento. > > Una system call può non terminare o impiegare tempi anche biblici per > diversi motivi, ad esempio: > * si sta cercando di accedere ad una risorsa (solitamente remota) che > non è disponibile (es: un file system NFS) [in questo caso dovrebbe > bastare rendere disponibile la risorsa, es: montare il file system NFS] > * un bug hardware > * un bug di Linux > > Oh! La cosa che mi incuriosiva era il perchè non venisse ucciso e direi che l'hai spiegato benissimo. Ci fossero svilupppi, per completezza, li comunico. Grazie very much
Re: Processo immortale
On 02/10/2018 09:19, Paolo Nicorelli wrote: C'è il processo utente con PID 9583 che gira dal 21 Agosto. kill -9 e sudo kill -9 non danno errori ma il processo rimane li Non è zombie, è in stato R pstree dice che il padre è init. il comando kill -9 lancia una chiamata asincrona per l'uccisione del processo indicato, se però il processo sta eseguendo una system call, allora questa può bloccare SIGKILL fino al suo completamento. Una system call può non terminare o impiegare tempi anche biblici per diversi motivi, ad esempio: * si sta cercando di accedere ad una risorsa (solitamente remota) che non è disponibile (es: un file system NFS) [in questo caso dovrebbe bastare rendere disponibile la risorsa, es: montare il file system NFS] * un bug hardware * un bug di Linux Però penso che gli ultimi due casi dovrebbero porre il processo nello stato D. Visto che il tuo processo è nello stato di running R dovresti capire cosa sta aspettando per risvegliarlo dallo sleep. Per individuare cosa sta aspettando si può provare in diversi modi: * cat /proc/PID/syscall * lsof -p PID (come ti hanno già suggerito) * strace -p PID * gdb PERCORSO_ALL'ESEGUBILE PID Guardando quanto hai postato per lsof > php 9583 userXXX 3u sock 0,8 0t0 485569960 can't identify protocol > php 9583 userXXX 5u sock 0,8 0t0 485583014 can't identify protocol direi che il problema potrebbe essere causato da questi due. Potrebbero essere dei socket che non sono stati chiusi correttamente dovresti vederli in stato CLOSE_WAIT anche eseguendo questo: # netstat -putan Però: 1) non so se è possibile terminare dei socket in quello stato... se non uccidendo il processo che li ha generati :-( 2) se il problema è questo, secondo me, l'unica è correggere il sorgente dove vengono aperti e farglieli chiudere correttamente... e a questo punto non so se puoi sostituire l'eseguibile (può essere uno script) Provare ad ucciderlo con gdb: gdb -p PID > kill Kill the program being debugged? (y or n) y > quit Se non funziona neanche così, dopo aver fatto il punto 2 devi riavviare la macchina... o far si che il processo abbia un altro nome (in modo che possa partire) e lasciare quello attivo in sleep. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Petizione contro il formato ms-ooxml: http://www.noooxml.org/petition Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Processo immortale
On Tue, 2 Oct 2018 at 11:29, Paolo Redælli wrote: > lsof -p 9583 > > userXXX@SERVERONE:/var/www/appBackend/RM_cron/appweb$ lsof -p 9583 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME php 9583 userXXX cwdDIR8,1 4096131073 /home/userXXX php 9583 userXXX rtdDIR8,1 4096 2 / php 9583 userXXX txtREG8,1 9045160 36396 /usr/bin/php5 php 9583 userXXX memREG8,1 22952 3256 /lib/x86_64-linux-gnu/libnss_dns-2.19.so php 9583 userXXX memREG8,1 47712 3208 /lib/x86_64-linux-gnu/libnss_files-2.19.so php 9583 userXXX memREG8,1167096 3248 /lib/x86_64-linux-gnu/libtinfo.so.5.9 php 9583 userXXX memREG8,1179184 10831 /usr/lib/x86_64-linux-gnu/libedit.so.2.0.47 php 9583 userXXX memREG8,1 31472140432 /usr/lib/php5/20121212/readline.so php 9583 userXXX memREG8,1 36008140431 /usr/lib/php5/20121212/pdo_mysql.so php 9583 userXXX memREG8,1 1193124671586 /usr/lib/newrelic-php5/agent/x64/newrelic-20121212.so php 9583 userXXX memREG8,1151168140424 /usr/lib/php5/20121212/mysqli.so php 9583 userXXX memREG8,1 3355232 2809 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 php 9583 userXXX memREG8,1 56304140429 /usr/lib/php5/20121212/mysql.so php 9583 userXXX memREG8,1187824 32485 /usr/lib/libmcrypt.so.4.4.8 php 9583 userXXX memREG8,1 47872139853 /usr/lib/php5/20121212/mcrypt.so php 9583 userXXX memREG8,1 68608131369 /usr/lib/php5/20121212/json.so php 9583 userXXX memREG8,1 23512848 10907 /usr/lib/x86_64-linux-gnu/libicudata.so.52.1 php 9583 userXXX memREG8,1 55304 10490 /usr/lib/x86_64-linux-gnu/libicuio.so.52.1 php 9583 userXXX memREG8,1 1525776 10885 /usr/lib/x86_64-linux-gnu/libicuuc.so.52.1 php 9583 userXXX memREG8,1 2121040 10471 /usr/lib/x86_64-linux-gnu/libicui18n.so.52.1 php 9583 userXXX memREG8,1401880131427 /usr/lib/php5/20121212/intl.so php 9583 userXXX memREG8,1104936 3123 /lib/x86_64-linux-gnu/libaudit.so.1.0.0 php 9583 userXXX memREG8,1 90160 3165 /lib/x86_64-linux-gnu/libgcc_s.so.1 php 9583 userXXX memREG8,1979056 10848 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 php 9583 userXXX memREG8,1 55856 21152 /lib/x86_64-linux-gnu/libpam.so.0.83.1 php 9583 userXXX memREG8,1 31792 3101 /lib/x86_64-linux-gnu/librt-2.19.so php 9583 userXXX memREG8,1 34265759265259 /opt/ibm/dsdriver/lib/libdb2.so.1 php 9583 userXXX memREG8,1285027135780 /usr/lib/php5/20121212/ibm_db2.so php 9583 userXXX memREG8,1 22616 10844 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 php 9583 userXXX memREG8,1 14456 10770 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 php 9583 userXXX memREG8,1125392 10832 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 php 9583 userXXX memREG8,1 58120 30123 /usr/lib/x86_64-linux-gnu/libjbig.so.0 php 9583 userXXX memREG8,1170064 3161 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 php 9583 userXXX memREG8,1 1265072 10756 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 php 9583 userXXX memREG8,1467208 30128 /usr/lib/x86_64-linux-gnu/libtiff.so.5.2.0 php 9583 userXXX memREG8,1 1677008 17624 /usr/lib/x86_64-linux-gnu/libvpx.so.1.3.0 php 9583 userXXX memREG8,1244704 30069 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0 php 9583 userXXX memREG8,1666080 10944 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1 php 9583 userXXX memREG8,1153936 3238 /lib/x86_64-linux-gnu/libpng12.so.0.50.0 php 9583 userXXX memREG8,1281288 30107 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2 php 9583 userXXX memREG8,1 72776 17631 /usr/lib/x86_64-linux-gnu/libXpm.so.4.11.0 php 9583 userXXX memREG8,1417992 17639 /usr/lib/x86_64-linux-gnu/libgd.so.3.0.0 php 9583 userXXX memREG8,1109968131417 /usr/lib/php5/20121212/gd.so php 9583 userXXX memREG8,1 43368 3198 /lib/x86_64-linux-gnu/libcrypt-2.19.so php 9583 userXXX memREG8,1754880 10881 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 php 9583 userXXX memREG8,1295816 10835 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 php 9583 userXXX memREG8,1 56768 10896 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 php 9583 userXXX memREG8,1166040 10478 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 php 9583 userXXX memREG8,1 30944 10933
Re: Processo immortale
On Tue, Oct 02, 2018 at 11:00:56AM +0200, Paolo Nicorelli wrote: > On Tue, 2 Oct 2018 at 10:52, liste DOT girarsi AT posteo DOT eu < > liste.gira...@posteo.eu> wrote: > > > Spegni il server! > > > > :D :D :D :D > > Ho scritto qui proprio perchè mi hanno cassato questa soluzione > > :D :D :D :D Riavviare apache? -- Felipe Salvador
Re: Processo immortale
Il 02/10/2018 09:19, Paolo Nicorelli ha scritto: Quando uccidere diventa facile come respirare, è il momento di fare qualcosa per l'alito. (Rat-Man) Ciao, non succede su una macchina mia ma su un server di un'amica. C'è il processo utente con PID 9583 che gira dal 21 Agosto. è uno script in php che il cron dovrebbe lanciare ogni ora, però sembra che sia piantato e non faccia nulla (strace è muto) kill -9 e sudo kill -9 non danno errori ma il processo rimane li Non è zombie, è in stato R pstree dice che il padre è init. Da quello che ho capito dentro lo script ci sono - un controllo che se c'è già il processo in running esce (check sul nome) - un sync con un'altra macchina attraverso la rete (o SOAP o sFTP) come mai non muore? lsof -p 9583 cosa dice? Situazioni simili mi sono accadute quando c'era di mezzo NFS
Re: Processo immortale
Il 2 ottobre 2018 10:48:00 CEST, Paolo Nicorelli ha scritto: >On Tue, 2 Oct 2018 at 09:48, liste DOT girarsi AT posteo DOT eu < >liste.gira...@posteo.eu> wrote: > >> Probabile che sia in ambiente utente che non funziona, facendolo da >> amministratore globale forse funzia. >> > >Provato, rimane li. killall -9 -w nome rimane appeso fino a che il processo muore effettivamente (così te ne trovi due bloccati invece di uno ;-P) byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Re: Processo immortale
On Tue, 2 Oct 2018 at 10:52, liste DOT girarsi AT posteo DOT eu < liste.gira...@posteo.eu> wrote: > Spegni il server! > :D :D :D :D Ho scritto qui proprio perchè mi hanno cassato questa soluzione :D :D :D :D
Re: Processo immortale
Il 02/10/2018 10:48, Paolo Nicorelli ha scritto: On Tue, 2 Oct 2018 at 09:48, liste DOT girarsi AT posteo DOT eu < liste.gira...@posteo.eu> wrote: Probabile che sia in ambiente utente che non funziona, facendolo da amministratore globale forse funzia. Provato, rimane li. Spegni il server! -- _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| Simone Girardelli
Re: Processo immortale
On Tue, 2 Oct 2018 at 09:48, liste DOT girarsi AT posteo DOT eu < liste.gira...@posteo.eu> wrote: > Probabile che sia in ambiente utente che non funziona, facendolo da > amministratore globale forse funzia. > Provato, rimane li.
Re: Processo immortale
Il 02/10/2018 09:19, Paolo Nicorelli ha scritto: Quando uccidere diventa facile come respirare, è il momento di fare qualcosa per l'alito. (Rat-Man) Ciao, non succede su una macchina mia ma su un server di un'amica. C'è il processo utente con PID 9583 che gira dal 21 Agosto. è uno script in php che il cron dovrebbe lanciare ogni ora, però sembra che sia piantato e non faccia nulla (strace è muto) kill -9 e sudo kill -9 non danno errori ma il processo rimane li Non è zombie, è in stato R pstree dice che il padre è init. Da quello che ho capito dentro lo script ci sono - un controllo che se c'è già il processo in running esce (check sul nome) - un sync con un'altra macchina attraverso la rete (o SOAP o sFTP) come mai non muore? Al posto di sudo, andrei di root globale, non utente con: su - Poi: # kill -9 PID Probabile che sia in ambiente utente che non funziona, facendolo da amministratore globale forse funzia. -- _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| Simone Girardelli
Processo immortale
Quando uccidere diventa facile come respirare, è il momento di fare qualcosa per l'alito. (Rat-Man) Ciao, non succede su una macchina mia ma su un server di un'amica. C'è il processo utente con PID 9583 che gira dal 21 Agosto. è uno script in php che il cron dovrebbe lanciare ogni ora, però sembra che sia piantato e non faccia nulla (strace è muto) kill -9 e sudo kill -9 non danno errori ma il processo rimane li Non è zombie, è in stato R pstree dice che il padre è init. Da quello che ho capito dentro lo script ci sono - un controllo che se c'è già il processo in running esce (check sul nome) - un sync con un'altra macchina attraverso la rete (o SOAP o sFTP) come mai non muore?
