Perlscript работает нормально, когда выполняется вручную, но не под Cron

5291
zedoo

моя настройка беспроводной сети не работает несколько раз в день, помогает перезагрузка сетевого менеджера gnome. Я хочу автоматизировать это и взломал следующий 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"; }

Моим первым тестом было просто убить nm-апплет вручную и запустить скрипт вручную. Он не обнаруживает никаких соединений и просто «превращается» в nm-апплет, как и предполагалось.

Теперь тот же тест, но выполняемый следующим заданием cron: 

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

Вывод в netcheck.log - это просто «Запуск nm-applet ...», но он не запускается. Процесс просто умирает сразу.

Любая помощь или, возможно, другое решение приветствуется.

0
#! / Нам / бен / Perl? Richie Marquez 15 лет назад 0
@Rich: Хороший глаз, но я предполагаю, что если сценарий дойдет до «Запуск nm-applet ...». это опечатка. Telemachus 15 лет назад 0

4 ответа на вопрос

2
nagul

As everyone who answered has already pointed out, cron runs commands in a very minimal environment. I'd suggest you try this in sequence:

  1. Use the full path for any calls made in the script.

  2. In the crontab entry, execute the script explicitly using perl.

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

  3. Capture both stdout and stderr output of the script.

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

  4. Temporarily replace exec "nm-applet" with exec "ls" or some other simple command to check that the problem is with the environment nm-applet expects, not with the script itself.

  5. Check if executing nm-applet –sm-disable helps.
  6. If you're still stuck, execute strace nm-applet instead to trace the system calls. Run this normally and within cron to identify the call from which the logs diverge. Debug from that point.

Having said this, I'm not surprised to see nm-applet failing to run properly from within cron. It probably needs access to the display and gnome libraries that are missing from within the cron environment. An at job might be better, but even that isn't ideal. I'd recommand using wicd instead if you need to reconnect from a cron job.

хорошо, я проверю Wicd. zedoo 15 лет назад 0
Установлен WICD, кажется, очень гладко. zedoo 15 лет назад 0
1
Telemachus

Cron работает в очень минимальной среде. Укажите явные, полные пути для всех команд оболочки (например, /sbin/pingвместо pingи т. Д. - проверьте, где сначала находятся соответствующие элементы whereis pingи т. Д.), И он, вероятно, будет работать нормально.

Не имеет никакого эффекта zedoo 15 лет назад 0
1
bmb

Вообще говоря, вы не можете запускать приложения с графическим интерфейсом из cron, поскольку у cron нет среды, рабочего стола, дисплея и т. Д.

Попробуйте это в cron

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

или вместо установки DISPLAY в crontab, попробуйте установить его в самом скрипте. Я не уверен, какой путь будет работать.

Возможно, вам также придется заняться утомительным хулиганством с xauth. David Mackintosh 15 лет назад 0
Это звучит разумно. Я предполагаю, что настоящая проблема заключается в том, что моя сетевая среда управляется настольным приложением. zedoo 15 лет назад 0
0
EmmEff

В своем скрипте попробуйте вывести системный PATH перед вызовом exec nm-applet. nm-applet существует в / usr / bin в моей системе, и я не могу представить, что PATH по умолчанию не содержит / usr / bin, но произошли странные вещи.

Я изменил аргумент exec на абсолютный путь. Ничего не меняет zedoo 15 лет назад 0

Похожие вопросы