As everyone who answered has already pointed out, cron runs commands in a very minimal environment. I'd suggest you try this in sequence:
- Use the full path for any calls made in the script.
In the crontab entry, execute the script explicitly using perl.
/usr/bin/perl /home/joe/netcheck.pl
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 &
Temporarily replace
exec "nm-applet"
withexec "ls"
or some other simple command to check that the problem is with the environment nm-applet expects, not with the script itself.- Check if executing
nm-applet –sm-disable
helps. - 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.