my wireless setup fails several times a day, restarting gnome's network manager helps. I want to automate this and hacked the following perlscript:


use strict;
use warnings;

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

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";

My first test was to just kill nm-applet by hand and running the script manually. It detects no connectivity and just "morphs" into nm-applet, just as intended.

Now the same test but executed by the following cron job:

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

The output in netcheck.log is just "Starting nm-applet..." but it doesn't get started. The process just dies immediately.

Any help or possibly other solution appreciated.

  • #!/us/bin/perl? Sep 23, 2009 at 21:47
  • @Rich: Good eye, but I assume that if the script gets as far as "Starting nm-applet...". that's a typo.
    – Telemachus
    Sep 23, 2009 at 22:17

4 Answers 4


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.

  • nice, i'll check out wicd.
    – zedoo
    Sep 24, 2009 at 16:19
  • installed wicd, seems very slick.
    – zedoo
    Sep 24, 2009 at 18:54

Cron runs under a very minimal environment. Supply explicit, full paths for all shell commands (e.g., /sbin/ping instead of ping and so on - check where the relevant items are first with whereis ping and so on), and it will likely run fine.

  • Has no effect.
    – zedoo
    Sep 23, 2009 at 21:52

Generally speaking, you can't start GUI apps from cron, since cron has no environment, desktop, display, etc.

Try this in cron

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

or instead of setting DISPLAY in the crontab, try setting it in the script itself. I'm not sure which way will work.

  • You might also have to do some tedious mucking about with xauth too. Sep 24, 2009 at 2:35
  • This sounds reasonable. I guess the real problem here is that my networking environment is managed by a desktop application..
    – zedoo
    Sep 24, 2009 at 8:41

In your script, try dumping the system PATH before the "exec nm-applet" call. nm-applet exists in /usr/bin on my system, and I cannot imagine the default PATH not containing /usr/bin but stranger things have happened.

  • I changed the exec argument to an absolute path. Doesn't change anything.
    – zedoo
    Sep 23, 2009 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.