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: Thunderbird 60 su stable e testing ancora con 52
On 02/10/2018 18:28, Francesco Porro wrote: Il 02/10/2018 16:33, peterpunk ha scritto: Trattandosi di un aggiornamento di sicurezza(*), è possibile che per questo sia arrivato su stable prima che su testing. (*) https://packages.debian.org/search?keywords=thunderbird=names=stable=all Però, correggetemi se sbaglio, anche testing ha il suo repo per gli aggiornamenti di sicurezza. Quindi, perché non rilasciarlo anche per testing/Buster? Se non contemporaneamente, poco dopo... È questo che non mi spiego. il repository di sicurezza di testing non è detto che sia sempre aggiornato ed è mantenuto al 100% solo durante il freeze per la nuova stable. Di solito in stable non arrivano mai pacchetti più aggiornati tranne alcune eccezioni: * Linux: per permettere il supporto a dispositivi recenti * alcuni programmi abbastanza corposi e su cui i DD di Debian hanno litigato un po' con l'upstream che non permette di avere puntualmente le modifiche di sicurezza, come nel caso di Mozilla e quindi hanno deciso di portare in alcuni casi la nuova versione. Inoltre in testing sono in atto delle transazioni e una è su mozilla, quindi probabilmente è questa che tiene bloccato l'aggiornamento. Io uso testing ed ho messo anche il repository di sicurezza di stable (può capitare che arrivi un pacchetto aggiornato in stable sul repository di sicurezza che può essere installato senza problemi anche in testing: se la versione di partenza è la stessa e anche le versioni delle dipendenze). Però sia thunderbird che firefox di stable, presenti sui repository di sicurezza, non possono essere installati in testing perché le librerie da cui dipendono sono diverse come versione (cioè le dipendenze in stable sono su librerie più vecchie). Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Database: http://www.postgresql.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Thunderbird 60 su stable e testing ancora con 52
Il 02/10/2018 16:33, peterpunk ha scritto: > > Trattandosi di un aggiornamento di sicurezza(*), è possibile che per > questo sia arrivato su stable prima che su testing. > > (*) > https://packages.debian.org/search?keywords=thunderbird=names=stable=all > > peterpunk Grazie! Questa è senz'altro parte della spiegazione. Però, correggetemi se sbaglio, anche testing ha il suo repo per gli aggiornamenti di sicurezza. Quindi, perché non rilasciarlo anche per testing/Buster? Se non contemporaneamente, poco dopo... È questo che non mi spiego. -- fp
Re: Thunderbird 60 su stable e testing ancora con 52
Il 02/10/2018 16:47, Marco Nicola ha scritto: Ciao a tutti volevo sospendere la registrazione al forum .. Qualcuno potrebbe cortesemente indicarmi come fare ? Grazie 1000 ciao, primo, non è un forum, secondo, non si usa appiccicarsi ad altri argomenti. terzo: eccolo https://www.debian.org/MailingLists/unsubscribe valerio
Re: Thunderbird 60 su stable e testing ancora con 52
Ciao a tutti volevo sospendere la registrazione al forum ..
Qualcuno potrebbe cortesemente indicarmi come fare ?
Grazie 1000
On Tue, Oct 2, 2018 at 4:40 PM peterpunk wrote:
> On Tue, 2 Oct 2018 15:00:30 +0200 Francesco wrote:
>
> > Salve a tutti,
> >
> > sono su testing da qualche mese come distro principale e mi trovo
> > molto bene.
> >
> > Ho un dubbio riguardante il client di posta che uso, Mozilla
> > Thunderbird, visto che la versione ESR 60 (Quantum) è stata resa
> > disponibile su Stable (Stretch) già da qualche settimana, mentre su
> > testing (Buster) siamo ancora alla 52.9.
> > (...)
>
> Trattandosi di un aggiornamento di sicurezza(*), è possibile che per
> questo sia arrivato su stable prima che su testing.
>
> (*)
>
> https://packages.debian.org/search?keywords=thunderbird=names=stable=all
>
> peterpunk
> --
>
> ,= ,-_-. =.
> ((_/)o o(\_))
> `-'(. .)`-'
> \_/ printf("Mai un giorno senza una riga\n");
>
>
Re: Thunderbird 60 su stable e testing ancora con 52
On Tue, 2 Oct 2018 15:00:30 +0200 Francesco wrote:
> Salve a tutti,
>
> sono su testing da qualche mese come distro principale e mi trovo
> molto bene.
>
> Ho un dubbio riguardante il client di posta che uso, Mozilla
> Thunderbird, visto che la versione ESR 60 (Quantum) è stata resa
> disponibile su Stable (Stretch) già da qualche settimana, mentre su
> testing (Buster) siamo ancora alla 52.9.
> (...)
Trattandosi di un aggiornamento di sicurezza(*), è possibile che per
questo sia arrivato su stable prima che su testing.
(*)
https://packages.debian.org/search?keywords=thunderbird=names=stable=all
peterpunk
--
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/ printf("Mai un giorno senza una riga\n");
Thunderbird 60 su stable e testing ancora con 52
Salve a tutti, sono su testing da qualche mese come distro principale e mi trovo molto bene. Ho un dubbio riguardante il client di posta che uso, Mozilla Thunderbird, visto che la versione ESR 60 (Quantum) è stata resa disponibile su Stable (Stretch) già da qualche settimana, mentre su testing (Buster) siamo ancora alla 52.9. C'è sicuramente qualche ragione che mi sfugge, perché così a prima vista non mi pare una scelta molto logica (essendo i repo di testing più "aggiornati" per definizione). Mi illuminate? -- fp
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
Stretch - Evolution > Exchange - rubrica con domini errati
Buongiorno Lista, a lavoro abbiamo un server exchange (SBS2011) con cui mi connetto tramite evolution. Abilitando l'auto completamento degli indirizzi di posta mi succede quanto segue: In azienda utilizziamo due standard in fatto di indirizzi e-mail. Alcuni colleghi hanno solo un indirizzo .it, altri solo .com, alcuni di quelli che hanno .com hanno anche .it. Gli indirizzi .com sono gestiti da exchange, quelli .it risiedono su di un server esterno, gestiti da postfix. Siamo noi ad aggiungere manualmente gli indirizzi .it nella rubrica exchange, che diversamente non avrebbe modo di reperirli. Gli indirizzi sono tutti nome.cognome@dominio.[it/com] Quando cerco un indirizzo .com di un utente che ha .com o .com+.it tutto ok. Quando cerco .it di un utente che ha solo .it, evolution mi aggiunge alla lista dei disponibili anche un indirizzo .com, che in realtà non esiste. Sta cosa chiaramente e' snervante, il rischio e' quello di inviare e-mail a indirizzi inesistenti e l'unico rimedio e' quello di chiedere a chi usa l'altro sistema se l'indirizzo esista o meno. Avete avuto esperienze simili? Come avete risolto? Grazie -- Felipe Salvador
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?
