Perlscript roda bem quando executado manualmente, mas não sob o cron

0

minha configuração sem fio falha várias vezes ao dia, reiniciar o gerenciador de rede do gnome ajuda. Eu quero automatizar isso e hackear o seguinte perlscript:

#!/usr/bin/perl                                                                                                                                                   

use strict;
use warnings;

my $result = system "ping -c1 -W1 192.168.1.1";

if ($result != 0) {
  print "No connectivity. Action required...\n";
  my $pid = 'pgrep nm-applet';
  if ($pid) {
    print "Killing current nm-applet instance $pid\n";
    system "kill $pid";
  }

  print "Starting nm-applet...";
  exec "nm-applet" or die "couldn't start nm-applet";

} else {
  print "Looks all fine. No action required\n";
}

Meu primeiro teste foi apenas matar manualmente o nm-applet e executar o script manualmente. Ele não detecta conectividade e apenas "se transforma" em nm-applet, exatamente como pretendido.

Agora, o mesmo teste, mas executado pela seguinte tarefa do cron:

*/1 * * * * /home/joe/netcheck.pl >> /home/joe/netcheck.log &

A saída no netcheck.log é apenas "Iniciando o nm-applet ...", mas ele não é iniciado. O processo simplesmente morre imediatamente.

Qualquer ajuda ou possivelmente outra solução apreciada.

    
por zedoo 23.09.2009 / 23:13

4 respostas

2

Como todos que responderam já pontuaram, o cron executa comandos em um ambiente mínimo. Eu sugiro que você tente isso em sequência:

  1. Use o caminho completo para todas as chamadas feitas no script.
  2. Na entrada crontab, execute o script explicitamente usando perl.

    /usr/bin/perl /home/joe/netcheck.pl

  3. Capture a saída stdout e stderr do script.

    /usr/bin/perl /home/joe/netcheck.pl 1>/home/joe/netcheck-stdout.log 2>/home/joe/netcheck-stderr.log &

  4. Substitua temporariamente exec "nm-applet" por exec "ls" ou algum outro comando simples para verificar se o problema está no ambiente que o applet nm espera, não com o próprio script.

  5. Verifique se a execução de nm-applet –sm-disable ajuda.
  6. Se você ainda estiver preso, execute strace nm-applet para rastrear as chamadas do sistema. Execute isto normalmente e dentro do cron para identificar a chamada da qual os logs divergem. Depurar a partir desse ponto.

Dito isto, não me surpreendo ao ver o nm-applet não rodando corretamente dentro do cron. Provavelmente precisa de acesso às bibliotecas do monitor e do gnome que estão faltando no ambiente do cron. Um emprego pode ser melhor, mas nem isso é ideal. Eu recomendo usar wicd em vez disso, se você precisar se reconectar a partir de um cron job.

    
por 24.09.2009 / 16:13
1

O Cron é executado em um ambiente muito mínimo. Forneça caminhos explícitos e completos para todos os comandos do shell (por exemplo, /sbin/ping em vez de ping e assim por diante - verifique onde os itens relevantes são primeiro com whereis ping e assim por diante) e ele provavelmente será executado corretamente. >     

por 23.09.2009 / 23:45
1

Em geral, você não pode iniciar aplicativos GUI a partir do cron, já que o cron não possui ambiente, área de trabalho, exibição, etc.

Tente isso no cron

*/1 * * * * export DISPLAY=:0 && /home/joe/netcheck.pl >> /home/joe/netcheck.log &

ou, em vez de configurar DISPLAY no crontab, tente defini-lo no próprio script. Não tenho certeza de qual caminho funcionará.

    
por 24.09.2009 / 00:55
0

Em seu script, tente descarregar o PATH do sistema antes da chamada "exec nm-applet". nm-applet existe em / usr / bin em meu sistema, e não consigo imaginar o PATH padrão que não contém / usr / bin, mas coisas estranhas aconteceram.

    
por 23.09.2009 / 23:21