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

Carlos Eduardo Langoni ce.langoni at gmail.com
Wed Sep 29 15:04:18 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".
> 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 :(
> 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
> 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
> Tento setar o environment manualmente pois sei que cron não seta tudo, só o
> dito "essencial"
> 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
> 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
> 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í?!?!

Stanislaw,

Todos os seus processos criados para o cron estão sendo enviados para bg?

"01,31 * * * * stats.pl &>/dev/null".

IMHO esta linha está errada, não existe necessidade de se utilizar &
no final de um comando chamado pelo cron.
Eu já utilizei o importador em php do mysar (sistema de relatório do
squid) em sistemas que demoravam muito mais do que 1 minuto para
importar os logs e nunca tive "problemas" o que eu tive foram milhares
de processos duplicados e slow performance no sistema, pois todos
tentavam ler praticamente a mesma coisa.

Avalie esta questão e remova o > /dev/null para que o cron possa te
enviar toda saída via mail no sistema.
Vale também seguir o que o Alexei falou e acompanhar o syslog com tail
-f /var/log/syslog | grep CRON para ter certeza de que o cron está
chamando o script ou exibindo algum erro estranho.

Qualquer coisa avisa aí!

Abraços


More information about the SaoPaulo-pm mailing list