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: Thunderbird 60 su stable e testing ancora con 52
Il 03/10/18 13:35, Gabriele Stilli ha scritto: > Il 02/10/2018 15:00, Francesco Porro ha scritto: > >> 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. > > Da queste pagine: > https://tracker.debian.org/pkg/thunderbird > https://buildd.debian.org/status/package.php?p=thunderbird > parrebbe che ci siano problemi di dipendenze (cargo e rustc) su mips e > mipsel. > > Gabriele :-) > insomma se il pacchetto non si compila su tutte le piattaforme non viene passato su testing. Ho capito bene? Nel frattempo ho preso Thunderbird da unstable, pinnando: thunderbird* lightning* Attenzione in particolare a quest'ultimo: l'asterisco serve a includere anche i vari l10n, senza i quali non andrebbe, su un'installazione localizzata (sono impazzito una mezzoretta a capire perché non ci fosse più il calendario xD). -- fp
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: Thunderbird 60 su stable e testing ancora con 52
Il 02/10/2018 15:00, Francesco Porro ha scritto: > 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. Da queste pagine: https://tracker.debian.org/pkg/thunderbird https://buildd.debian.org/status/package.php?p=thunderbird parrebbe che ci siano problemi di dipendenze (cargo e rustc) su mips e mipsel. Gabriele :-)
Re: Thunderbird 60 su stable e testing ancora con 52
Il 02/10/2018 20:27, Davide Prina ha scritto: > il repository di sicurezza di testing non è detto che sia sempre > aggiornato ed è mantenuto al 100% solo durante il freeze per la nuova > stable. Ok, questo ha senso... > Inoltre in testing sono in atto delle transazioni e una è su mozilla, quindi > probabilmente è questa che tiene bloccato l'aggiornamento. Quindi una volta terminata questa transizione (a proposito, c'è qualche pagina a riguardo che ne parla?) su Mozilla, secondo te ce lo ritroveremo in testing tramite main? Su Sid ormai c'è dal 19 agosto. Sto anche pensando di tirarlo dentro col pinning, di cui sono già abbastanza pratico, da unstable... Chiedevo anche per capire se valeva la pena di aspettare o meno. Graz -- fp
