Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

my wireless setup fails several times a day, restarting gnome's network manager helps. I want to automate this and hacked the following 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";
}

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.

share|improve this question
    
#!/us/bin/perl? –  Richard Marquez Sep 23 '09 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 '09 at 22:17

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
    
nice, i'll check out wicd. –  zedoo Sep 24 '09 at 16:19
    
installed wicd, seems very slick. –  zedoo Sep 24 '09 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.

share|improve this answer
    
Has no effect. –  zedoo Sep 23 '09 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.

share|improve this answer
    
You might also have to do some tedious mucking about with xauth too. –  David Mackintosh Sep 24 '09 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 '09 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.

share|improve this answer
    
I changed the exec argument to an absolute path. Doesn't change anything. –  zedoo Sep 23 '09 at 21:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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