[SP-pm] RES: [OT] cron e os processos pesados

[Stanislaw Pusep]

Consegui resolver! Veredicto: o cron é o culpado pelo assassinato dos meus
processos. Fiz o meu programa se daemonizar; assim o crond perde toda a
referência ao PID e o deixa rodar em paz:

if ($daemon) {
        if (fork) {
                exit;
        } else {
                setsid;
                if (fork) {
                        exit;
                } else {
                        die "Already running!" if
Proc::PID::File->running(dir => $RealBin, name => 'index');

                        open STDIN, '<', '/dev/null';
                        open STDOUT, '>', "$RealBin/index.log";
                        open STDERR, '>', "$RealBin/index.log";
                }
        }
} else {
        die "Already running!" if Proc::PID::File->running(dir => $RealBin,
name => 'index');
}

Valeu pelas dicas!

2010/10/5 Fabio Adriano Soares <Fabio.Soares em tivit.com.br>

>  Tenho um script que falhava da mesma maneira (com mensagem de Killed)
> porque faltava algumas variáveis de ambiente na hora da execução (o local de
> umas libs do db2). Faz um teste imprimindo o ambiente do usuário na cron e
> na console e compare.
>
>
>
> *De:* saopaulo-pm-bounces+fabio.soares=tivit.com.br em pm.org [mailto:
> saopaulo-pm-bounces+fabio.soares <saopaulo-pm-bounces%2Bfabio.soares>=
> tivit.com.br em pm.org] *Em nome de *Stanislaw Pusep
> *Enviada em:* terça-feira, 5 de outubro de 2010 18:05
>
> *Para:* saopaulo-pm em mail.pm.org
> *Assunto:* Re: [SP-pm] [OT] cron e os processos pesados
>
>
>
> Opa, juntando STDOUT e STDERR consegui uma pista! O cron envia isso no meu
> email:
>
>
> E: Some index files failed to download, they have been ignored, or old ones
> used instead.
> Fetched 160kB in 1min30s (1761B/s)
> /bin/sh: line 1:  5909 Killed                  iPhone/apt/index.pl--skipwp 2>&1
>
> "Killed", sem mais, nem menos. Neste ponto, o meu programa termina uma
> fase, de coleta de dados a partir de uma série de .txt, e começa a outra, a
> de atualização de uma tabela de 30 mil rows no MySQL.
> Se eu rodar só a fase 1 pelo cron, no final dela sempre dá um "Killed",
> entretanto tudo funciona OK, então chuto que o "Killed" acontece no garbage
> collection.
> Rodando somente a fase 2 pelo cron, às vezes dá "Killed", às vezes não.
> Portanto, imagino que logo na entrada da fase 2 torra muita RAM (*não
> deveria*, pois o processamento todo ocorre no MySQL). Se antes disso rodou a
> fase 1, a RAM já está "sujinha", então a chance do processo ser "Killed" é
> elevada.
> Que seja. Ainda assim, não entendo pq q funciona perfeitamente em 100% dos
> casos se eu rodar o processo manualmente, pelo terminal :(
>
> 2010/10/1 Stanislaw Pusep <creaktive em gmail.com>
>
> Basicamente, é isso: http://tinypaste.com/35fae
>
> 2010/10/1 Frederico Recsky <listas em imovlr.com>
>
>
>
> Olá,
>
> 2010/9/29 Stanislaw Pusep <creaktive em gmail.com>:
>
>
> > variáveis do environment da shell interativa) no script
> "/root/backup.sh".
> > Se rodo pela shell, funciona. Pelo cron, não funciona. Aí coloquei no
> cron
> > algo como "ssh root em localhost /root/backup.sh" (tendo definido uma chave
> > c/passphrase vazio previamente). E funcionou! O que poderia causar esse
> tipo
> > de problema, sem ser environment?!
>
> Rola de voce colar esse backup.sh em algum canto?
>
> []'s
>
> Frederico
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
>
>
>
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20101006/f645b7ff/attachment-0001.html>