0

So, I have a bash script that should pipe the output of ifconfig to a text file on the hour, every hour. As many people seem to have encountered, this script does not function properly when used by cron. However, most of the fixes for this that I have seen do not seem to be applicable in my case. I have all paths explicitly stated, the script has execute permissions, and there is a newline at the end of the cron file.

creatively enough, my scrip, ip.sh, contains:

ifconfig > /home/drake/Dropbox/maintenance_scripts/ip.txt

the cron entry is:

0 * * * *   /home/drake/Dropbox/maintenance_scripts/ip.sh

(i have it running every minute for debugging)

The BIG issue here is, when it runs, and it does run, is that it clears ip.txt of any contents it might have. Also, I have another script which does the same exact thing with uptime, and it works w/o any issues, which just has be confused. I have also tried >>, which seemed to yield identical results

So, Does anyone have any ideas why one script might function as expected, and another would just derp-out like this?

This is running on my Ubuntu server. I am using Dropbox to sync the text-files

Drake
  • 433
  • 2
  • 7
  • 17

3 Answers3

4

Your script should have a "shebang" line at the top:

#!/bin/sh

though it's not absolutely required.

The script overwrites ip.txt because you told it to. That's what the > redirection operator does. If you want to append to the end of the file, use >>. (You said you tried that, with identical results. I doubt that that's true. I suspect the cron job just isn't producing any output, so it's appending nothing to the file.)

But you don't need a separate script just to do the redirection; you can use > or >> in the cron job itself:

0 * * * *    ifconfig >> /home/drake/Dropbox/maintenance_scripts/ip.txt

And at least on my system, the default $PATH for cron jobs is /usr/bin:/bin, but ifconfig is /sbin/ifconfig. Try which ifconfig or type ifconfig to see where ifconfig lives on your system (we're both using Ubuntu, so it's probably the same), and use the full path in the cron job; for example:

0 * * * *    /sbin/ifconfig >> /home/drake/Dropbox/maintenance_scripts/ip.txt

And if you want to see when the output changed (I presume that's what you're checking for), it's easy enough to add a timestamp:

0 * * * *    ( date ; /sbin/ifconfig ) >> /home/drake/Dropbox/maintenance_scripts/ip.txt
Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • ah, i knew it had to be something like this. it does infact reside in /sbin/, and changing it to /sbin/ifconfig set things right. – Drake Jan 11 '12 at 00:29
  • 1
    You can accept an answer as the correct one by clicking the check mark icon next to it. Once you have 15 reputation points (which shouldn't take long), you can also upvote one or more answers if you're so inclined. – Keith Thompson Jan 11 '12 at 00:45
3

Try this one, it worked from the cron for me. Note that ifconfig output can change from Linux distribution to distribution so you may need to adjust the awk selections.

# Cron ifconfig piping is broken
eth0ipIC=`/sbin/ifconfig eth0`
eth0ip=`echo $eth0ipIC|awk '{print $7}'|awk -F: '{print $2}'`
AAber
  • 31
  • 1
3

The ip.sh script is supposed to zap the ip.txt file every time it is run; it is then up to the ifconfig program to repopulate it. So, your problem is that ifconfig isn't doing that.

The usual problem when running things from cron is environment. Note that when cron runs a command, the profile is not used.

In this case, I'd lay odds that the PATH setting under cron doesn't include the directory where ifconfig lives (so /sbin is not on PATH). Obvious workarounds:

  • /sbin/ifconfig ...
  • export PATH=$PATH:/sbin; ifconfig ...

I think simply running a script from the crontab file is usually the best way to do business. Without changing the crontab settings, you can add debug code, change the environment settings, and otherwise tinker to your heart's content. Fiddling with complex command lines in the crontab file is liable to run into trouble, sooner or later, on some system or other. So I think your system is sensible - I use a somewhat more complex system in my own cron-run scripts, but there is a lot of commonality. The key point is that the crontab entry is simple and the script that's run is where the complexity is hidden.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278