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

Wed Sep 29 15:18:24 PDT 2010

2010/9/29 Stanislaw Pusep <creaktive em gmail.com>:
> Valeu pelas dicas, pessoal!
> Verifiquei isso tudo. Esclarecendo:
>
> Não importa o usuário; não roda para nenhum, ou então roda e depois é
> "morto"
> Um exemplo de uma linha do crontab: "01,31 * * * * stats.pl &>/dev/null".

Não jogue a saída do comando para o /dev/null, afinal, você quer saber o que
está acontecendo.

Sugestão:

01,31 * * * * nohup time stats.pl >> /var/tmp/stats_debug.txt 2>&1

No script stats.pl você também deve verificar se está usando o interpretador
da forma correta (Ex.: #!/usr/bin/env perl), bem como suas permissões. Convêm
colar aqui também.

Não custa ver como anda o seu ambiente também:

* * * * * ( set && env ) >> myenv.txt 2>&1

> Sim, isso executa. Sendo que fui eu quem fiz esse script, mandei gerar uns
> logs e a coisa começa a rodar pelo cron. Mas, ÀS VEZES, não termina :(

A ideia de jogar os processo no background não é uma boa ideia, neste caso.
Primeiro é necessário saber quanto tempo eles (os processos) demoram para
executar, um simples "time" resolve. Se for um período razoável de tempo, você
vai ter que tomar providências.

> Quando o script não foi feito por mim, como no caso do rdiff-backup, não
> faço ideia do que possa estar acontecendo, nem chega no estágio que gera
> logs

Veja os fontes.

> O comando do ssh que usei como exemplo foi para demonstrar que cron lida
> suficientemente bem com o processo do ssh. Então o problema é o script

Humm.

> Tento setar o environment manualmente pois sei que cron não seta tudo, só o
> dito "essencial"

Algum comportamento do seu software é passado através das variáveis de
ambiente?

> Depois desse rolo todo, única coisa que me vem à cabeça é que cron aplica
> "ulimit" nos processos que cria. Em outros termos, os processos spawnados

Perai. Você mandou ele fazer isso? Não acredito que este seja o comportamento
padrão do crontab.

> rodam em "jail". Isso explicaria tudo: processo que estoura algum limite
> imposto é assassinado sem escrúpulos. Aliás, vi nos fóruns por aí que coisas

Você veria isso nos logs (/var/log/messages).

> que rodam do crontab tem dificuldades para setar "ulimit" eles mesmos, o que
> reforça a minha tese. Porém esse "feature" não é documentado em nenhum
> lugar!!! E aí?!?!

Calma.

> 2010/9/29 zechim, lucas <lzechim em gmail.com>
>>
>> Boa tarde,
>>
>> Verifique também se você não está direcionando a stdout e stderr para
>> /dev/null :)
>>
>> Lucas Zechim
>>
>>
>>
>>
>> 2010/9/29 Alexei Znamensky <russoz em gmail.com>:
>> >
>> >> 2010/9/29 Otávio Fernandes <otaviof em gmail.com>
>> >>>
>> >>> 2010/9/29 Stanislaw Pusep <creaktive em gmail.com>:
>> >>> > PessoALL, alguém aqui teve algum tipo de problema ao rodar coisas
>> >>> > relativamente pesadas a partir do cron? Vários scripts meus
>> >>> > apresentaram
>> >>> > variedade de problemas, como, por exemplo, processos muito demorados
>> >>> > serem
>> >>> > "assassinados" misteriosamente (sem que constasse nada nos reports
>> >>> > que
>> >>> > o
>> >>> > cron manda pro mailbox). Mas o mais bizarro foi o caso do
>> >>> > rdiff-backup
>> >>> > (http://rdiff-backup.nongnu.org/). No Ubuntu 10.04, simplesmente não
>> >>> > acontece nada ao chamar ele. Isto é, salvei todos os parâmetros (e
>> >>> > até
>> >>> > as
>> >>> > variáveis do environment da shell interativa) no script
>> >>> > "/root/backup.sh".
>> >
>> > Para verificar se a execução via cron está ou não funcionando de
>> > verdade,
>> > veja no syslog. Por exemplo, na minha máquina de casa:
>> > 17:25:09 BRT az em blueturtle:/var/log $ grep CRON syslog
>> > [...]
>> > Sep 29 08:15:01 blueturtle CRON[4288]: (root) CMD (/usr/sbin/service
>> > ondemand start >/dev/null 2>&1)Sep 29 08:17:01 blueturtle CRON[4337]:
>> > (root)
>> > CMD (   cd / && run-parts --report /etc/cron.hourly)
>> > Sep 29 08:33:01 blueturtle CRON[4566]: (root) CMD (/usr/sbin/ntpdate -u
>> >  ntp.ansp.br >/dev/null 2>&1)
>> > Sep 29 17:15:38 blueturtle CRON[4949]: (root) CMD (/usr/sbin/service
>> > ondemand start >/dev/null 2>&1)
>> > Sep 29 17:17:01 blueturtle CRON[5327]: (root) CMD (   cd / && run-parts
>> > --report /etc/cron.hourly)
>> >>>
>> >>> > 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?!
>> >
>> > Por "environment", estou presumindo que você quer dizer "environment
>> > variables". Nesse caso, o que faz você ter certeza de que o problema não
>> > é
>> > esse? Caso você veja no log que o script NÃO executou (chamando direto,
>> > ao
>> > invés dessa gambi do ssh), eu recomendo que você analise mais
>> > profundamente
>> > se não há mesmo dependências de variáveis de ambiente que podem estar
>> > sendo
>> > setadas em algum dos arquivos de configuração do usuário ( .profile,
>> > .bash_profile, .bashrc, ou algo nessa linha ). O cron NÃO usa esses
>> > arquivos
>> > na execução.
>> > []s,
>> > --
>> > Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com]
>> > [www.flickr.com/photos/alexeiz]
>> > «Only love / Can bring the rain / That makes you yearn to the sky»
>> >
>> > _______________________________________________
>> > 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
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>

-- 
Otávio Fernandes
otaviof at ( gmail.com, cpan.org )
http://github.com/otaviof