Comportamento errático do job CRON com o shell script do Bourne

Question

Eu tenho o seguinte script, que é executado normalmente quando digito o nome do script no prompt (logscript):

#!/bin/sh
dvar='date +"%m\/%d\/%y"'
filedate='date +%b%d%Y'
echo DSS1 > serverlog_${filedate}.txt
grep "^$dvar" oasErrLog >> serverlog_${filedate}.txt
echo CMX1 >> serverlog_${filedate}.txt
ssh GVECMX1 grep "^$dvar" /home/gve/log/oasErrLog >> serverlog_${filedate}.txt
echo CMX2 >> serverlog_${filedate}.txt
ssh GVECMX2 grep "^$dvar" /home/gve/log/oasErrLog >> serverlog_${filedate}.txt
echo XIS1 >> serverlog_${filedate}.txt
ssh GVEXIS1 grep "^$dvar" /home/gve/log/oasErrLog >> serverlog_${filedate}.txt
echo XIS2 >> serverlog_${filedate}.txt
ssh GVEXIS2 grep "^$dvar" /home/gve/log/oasErrLog >> serverlog_${filedate}.txt
scp serverlog_${filedate}.txt "GVEXOSR2:C:/Documents\ and\ Settings/gve/Desktop/logs"
#rm serverlog_${filedate}.txt

A saída normal da amostra é:

DSS1
01/11/10 03:00:08.139 XIS run_backupserver - Startup of XISBACKUP backupserver complete.
CMX1
01/11/10 04:30:05.710 OMNICOMM 30274 - boatimesync: error 3 from boaRx rtu 35 pretry 1 {protocols/boa/boa_command.c:601}
01/11/10 04:30:12.117 OMNICOMM 30274 - CRC (0FFC) does not match calculated CRC (03B0) for remote JRS. headerLength=5 dataLength=0 crcByteOffset=2  functionCode=1  {protocols/boa/boa_io.c:1177}    
CMX2
XIS1
XIS2
01/11/10 03:00:10.563 XIS run_backupserver - Startup of XISBACKUP backupserver complete.

MAS quando eu configurei um trabalho CRON, ele roda e scps o arquivo, mas o conteúdo está errado, E o arquivo não está no servidor (quando a linha rm está comentada como mostrei acima). Aqui está a saída que estou recebendo, mas NOTA: a saída é alterada, ela varia de acordo com o resultado:

DSS1
CMX1
01/11/10 001/11/10 04:30:05.710 OMNICOMM 30274 - boatimesync: error 3 from boaRx rtu 35 pretry 1 {protocols/boa/boa_command.c:601}
01/11/10 04:30:12.117 OMNICOMM 30274 - CRC (0FFC) does not match calculated CRC (03B0) for remote JRS. headerLength=5 dataLength=0 crcByteOffset=2  functionCode=1  {protocols/boa/boa_io.c:1177}
CMX2
CMX2
CMX2
CMX2
XIS1
XIS1
XIS1
XIS1
XIS2
01/1101/11/10 001/11/10 03:00:10.563 XIS run_backupserver - Startup of XISBACKUP backupserver complete.

Alguma idéia de por que a tarefa CRON não está sendo executada exatamente como o sistema a executa quando o comando é digitado manualmente?

EDIT: Eu modifiquei o script para fazer o loop e com todo o endereçamento absoluto e modifiquei o arquivo CRON com as variáveis SHELL, PATH e HOME, mas a saída ainda é errática, aqui está o script agora:

#!/bin/sh

### internal variable definitions
dvar='date +"%m\/%d\/%y"'
filedate='date +%b%d%Y'

# add the prefix of new hosts into the string below
# which will be expanded later into GVE(whatever) while looping
HOSTLIST="DSS1 CMX1 CMX2 XIS1 XIS2"

# main Loop
for SUFFIX in $HOSTLIST
do
  echo $SUFFIX >> /home/gve/log/serverlog_${filedate}.txt
  ssh GVE$SUFFIX grep "^$dvar" /home/gve/log/oasErrLog \
    >> /home/gve/log/serverlog_${filedate}.txt
  echo "\n" >> /home/gve/log/serverlog_${filedate}.txt
done

# transfer and delete file
scp /home/gve/log/serverlog_${filedate}.txt \
  "GVEXOSR2:C:/Documents\ and\ Settings/gve/Desktop/logs"
#rm serverlog_${filedate}.txt

e aqui está a saída:

DSS1
01/1201/12/10 03:00:08.323 XIS run_backupserver - Startup of XISBACKUP backupserver complete.
1
01/12/101/12/10 00:00:37.003 agc - dbioLower: DNP prev cmd may still in prog, name NPC_GT3_GOV raiseTimeout 1250 lowerTimeout 2500 curtime(1263286837:3) cmd_time(1263286834:807)
01/12/10 02:14:57.545 OMNICOMM 1562 - CRC (F110) does not match calculated CRC (1110) for remote ARS. headerLength=5 dataLength=10 crcByteOffset=7  functionCode=2  {protocols/boa/boa_io.c:1177}


CMX2


XIS1


XIS1


XIS2
01/12/101/12/10 03:00:10.408 XIS run_backupserver - Startup of XISBACKUP backupserver complete.

Observe as datas confusas em algumas linhas, o '1' em vez de 'CMX1' e o 'XIS1' enganado.

EDIÇÃO FINAL:

Parece que, de alguma forma, o CRON gerou vários processos que estavam tropeçando uns nos outros. Depois de matar todos os processos aplicáveis, ele se endireitou. O CRON tem um histórico (se você fizer alguma pesquisa na web sobre ele) de spawns de processo múltiplo com bugs, então esteja atento.

    

Answer 1

A primeira regra do cron é configurar várias coisas que você espera. Um, em qual diretório você está (explicitamente 'cd' para ele). Dois, o caminho que você espera (no crontab, PATH = ...) e três, para onde o e-mail vai (se você quiser alterá-lo).

Por exemplo:

SHELL=/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log

Eu também teria cada script ou configuraria caminhos adicionais, se necessário, e sempre

cd $HOME

ou para outro caminho explícito.

    

Answer 2

O CRON tem seu próprio ambiente.

Você instalou o trabalho com o crontab -e como o usuário executando o trabalho? Como foi adicionado o trabalho?

Além disso, um pouco refazer o script, com looping; isso deve funcionar bem em sua configuração.

#!/bin/sh

### internal variable definitions
dvar='date +"%m\/%d\/%y"'
filedate='date +%b%d%Y'

# add the prefix of new hosts into the string below,
# which will be expanded later into GVE{whatever} while looping
HOSTLIST="DSS1 CMX1 CMX2 XIS1 XIS2"

# main processing loop
for SUFFIX in $HOSTLIST
do
  echo $SUFFIX >> serverlog_${filedate}.txt     
  ssh GVE$SUFFIX grep "^$dvar" /home/gve/log/oasErrLog \
    >> serverlog_${filedate}.txt
done

scp serverlog_${filedate}.txt \
  "GVEXOSR2:C:/Documents\ and\ Settings/gve/Desktop/logs"

Acompanhamento da segunda tentativa:

Ok, então algo está definitivamente em funcionamento. O fato de você ter 2x XIS1 é uma boa indicação de que os buffers não estão sendo escritos corretamente ou que o próprio shell é o culpado. O loop deve estar isolando cada host enquanto ele é executado, portanto, a menos que você tenha cachimbos / buffers sem efeito / espalhados, ele não deve mostrar XIS1 duas vezes seguidas. Tente explicitamente usar #!/bin/bash como o shell em vez de sh, às vezes os fornecedores re-hook sh para algo diferente de bash (e o loop é um bash-ism, então pode causar problemas). Além disso, coloque um sync antes do done no script, para ver se é um problema de armazenamento em buffer.