Problema frustrante em que nem o cron nem o su -c executam meu job (permissões?)

5

Atualizado (e recortado ) com mais detalhes abaixo.

Eu configurei um script cron e estou tentando depurar porque ele não está em execução. [teste de contexto snipped, tudo ok; veja a revisão 2 para detalhes] O comando em si, caso isso aconteça, (as setas indicam quebra de linha para legibilidade) é:

/usr/bin/php -C /etc /path/to/process.php
↪  >>/path/to/stdout.log 2>>/path/to/stderr.log

[teste de permissões ignoradas, o que está tudo bem; veja abaixo e revisão 2 para detalhes]

Verificando crontab (novamente, agrupado para legibilidade), recebo:

[blackero@XXXXXXXXXXX to]$ sudo crontab -u cronuser -l
MAIL="blackero@localhost"

30 9 * * * cronuser /usr/bin/php -C /etc /path/to/process.php
↪   >>/path/to/stdout.log 2>>/path/to/stderr.log
20 18 7 * * cronuser /usr/bin/php -C /etc /path/to/process.php
↪   >>/path/to/stdout.log 2>>/path/to/stderr.log
22 18 7 * * cronuser echo "Test" > /path/to/test.txt
↪   2> /path/to/error.txt

Atualização # 1 em 2012-02-08 12:32 Z

[Snip: Tendo tentado do derobert sugestão ( revisão 3 )] , eu sei que o cronuser pode executar o script corretamente e pode gravar nos dois arquivos .log . (Uma das primeiras coisas que o script process.php faz é baixar um arquivo por FTP; ele também está fazendo isso com sucesso.) Mas, mesmo depois de corrigir a linha MAIL="" (removendo-a e alterando-a para MAILTO="blackero@localhost" ), a tarefa cron ainda não funciona, nem me envia qualquer email.

Um amigo sugeriu que eu tentasse novamente

 9 12 8 * * cronuser /bin/echo "Test" > /var/www/eDialog/test.txt
 ↪  2> /var/www/eDialog/error.txt

tarefa, depois de passar o caminho completo para /bin/echo . Tendo apenas tentado isso, também não funcionou e também não gerou e-mail, por isso estou em uma perda.

Atualização # 2 em 2012-02-08 19:15 Z

Uma conversa de chat muito útil com oHessling , parece que o problema é com pam . Para cada vez que cron tentou executar meu trabalho, tenho /var/log/cron entradas:

crond[29522]: Authentication service cannot retrieve authentication info
crond[29522]: CRON (cronuser) ERROR: failed to open PAM security session: Success
crond[29522]: CRON (cronuser) ERROR: cannot set security context

Eu corrigi isso adicionando a seguinte linha a /etc/shadow :

cronuser:*:15217:0:99999:7:::

Como encontrei em um fórum , se o usuário não aparecer em /etc/shadow , então pam não continuará processando a solicitação de segurança. Adicionar * como a segunda coluna significa que esse usuário não pode efetuar login com uma senha (como nenhuma hash foi especificada). Corrigindo isso levou a um erro diferente em /var/log/cron , então, verificando novamente o meu crontab eu notei que eu tinha especificado o nome de usuário de cada vez.

Corrigir significa que meu crontab agora é:

[blackero@XXXXXXXXXXX ~]$ sudo crontab -u cronuser -l
MAILTO="blackero@localhost"

30 9 * * * /usr/bin/php -C /etc /path/to/process.php
↪   >>/path/to/stdout.log 2>>/path/to/stderr.log
52 18 8 * * /usr/bin/php -C /etc /path/to/process.php
↪   >>/path/to/stdout.log 2>>/path/to/stderr.log
9 12 8 * * /bin/echo "Test" > /path/to/test.txt
↪   2> /path/to/error.txt

mas agora /var/log/cron me mostra:

Feb  8 18:52:01 XXXXXXXXXXX crond[16279]: (cronuser) CMD (/usr/bin/php -C /etc
↪   /path/to/process.php >>/path/to/stdout.log 2>>/path/to/stderr.log)

e nada entra em stdout.log ou stderr.log . Nenhum email foi enviado para mim e nenhum dos outros arquivos em /var/log/ tem qualquer entrada no período de tempo correto, e estou ficando sem ideias quanto a onde procurar para ver o que está errado

    
por Owen Blacker 07.02.2012 / 20:00

3 respostas

0

Eu encontrei o problema. A -C opção da linha de comando que estou enviando para php , que deve foram -c . Eu não tenho idéia porque cron não estava relatando isso para mim em qualquer maneira, muito menos de uma maneira útil (ou como eu de alguma forma conseguiu obtê-lo em crontab com um capital C mas testá-lo no CLI com uma minúscula), mas executá-lo novamente no CLI com um colega aqui agindo como meu e de repente ficou óbvio.

Agora, quão idiota eu me sinto?

Bem, pelo menos está resolvido agora e cron está feliz em executar o meu maldito roteiro. Obrigado a todos por toda sua ajuda.

    
por 10.02.2012 / 15:52
6

Primeiro, quando um trabalho cron falha, o cron envia um email. Por padrão, isso é para o proprietário do trabalho cron. Então, esses e-mails provavelmente vão para o cronuser @ localhost ou talvez para o root @ localhost. Verifique essas caixas de email. Como alternativa, você pode especificar onde o email deve ir, colocando MAILTO=email@domain na parte superior do arquivo crontab. (Na verdade, vejo você colocar MAIL="" no topo do seu crontab. Pelo menos de acordo com man 5 crontab na minha máquina, ele deve ser MAILTO . E você não quer lançar mensagens de erro ao tentar descobrir por que não está funcionando!)

Em segundo lugar, o cron usa /bin/sh . Defina SHELL=/bin/bash (novamente, no topo do crontab) se você precisar de extensões de bash.

Em terceiro lugar, você não testou totalmente as permissões. Você precisa fazer algo como:

# su -s /bin/sh -u cronuser
$ touch /path/to/stdout.log
$ touch /path/to/stderr.log
$ cat /path/to/process.php > /dev/null
$ exit

para verificar completamente as permissões. cronuser pode estar faltando + x em um diretório pai, por exemplo. (Eu acho que você deveria checar / usr / bin / php também, mas eu suponho que é sensato)

Você também pode tentar executar o comando em um ambiente mínimo:

# su -s /bin/sh -u cronuser
$ env - /bin/sh
$ /usr/bin/php -C /etc /path/to/process.php

para ver se funciona.

    
por 07.02.2012 / 20:32
1

está em crond em execução?

Experimente um destes comandos:

pidof crond
pgrep -l crond
ps caxf | grep -6 crond --color

saída do último comando:

11881 ? S 0:00 \_ httpd 
11882 ? S 0:00 \_ httpd 
11883 ? S 0:00 \_ httpd 
11884 ? S 0:00 \_ httpd 
11885 ? S 0:00 \_ httpd 
11886 ? S 0:00 \_ httpd 
2098 ? Ss 0:01 crond             #this 'crond' is in red
2125 ? Ss 0:00 sudoscriptd 
2127 ? Ss 0:00 \_ sudoscriptd 
2136 tty2 Ss+ 0:00 mingetty 
2137 tty3 Ss+ 0:00 mingetty 
2138 tty4 Ss+ 0:00 mingetty 
2139 tty5 Ss+ 0:00 mingetty

Qual é a configuração crond ?

Verifique seu /etc/rc.d/init.d ou /etc/init.d ou o arquivo de inicialização.

A configuração crond pode listar os usuários negados ou / e permitidos .
Seu usuário é negado ? Verifique estes arquivos:

   /etc/cron.allow
   /etc/cron.deny

Se ambos os arquivos estiverem ausentes, somente o root é permitido .
Se cron.allow estiver ausente e cron.deny estiver vazio, todos os usuários serão permitidos por padrão.

O arquivo /etc/crontab deve ser gravável apenas para raiz:

$ ls -l /etc/crontab
-rw-r--r-- 1 root root 255 Jul 15  2006 /etc/crontab

O que diz crond ?

A maneira natural de receber informações de crond é o correio local. crond geralmente usa sendmail . Se sendmail não estiver disponível, é possível fornecer outro comando de correio ( CRONDARGS="-mmail" ).

Mas, neste estágio, o melhor é verificar diretamente o crond logs ( ll /var/log/cron* ).

Reinicie o crond

O problema pode ser corrigido ao reafirmar crond ...

Se o problema persistir, antes de outra reinicialização, vamos executá-lo sem init.d ou service e tentar outras opções:

sudo crond -p -x sch

Verifique novamente crond arquivos de log ...

    
por 08.02.2012 / 13:49