LinuxQuestions.org - cron job only runs halfway

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - cron job only runs halfway (https://www.linuxquestions.org/questions/linux-general-1/cron-job-only-runs-halfway-273140/)

cron job only runs halfway

I've got a cron.daily script that's supposed to pull a remote text file, force it all to lowercase, remove stupid windows formatting junk, and save it with the date in the filename. The job runs, but the final document is empty. When you run the script manually from the command line, it works gloriously...

Code:

# get the date, for the title

dater=`date +%b-%d-%Y`;



# pull the remote file

wget --tries=0 --retry-connrefused --output-document=/var/log/foo/temp --url of txt file--



# remove the stupid windows formatting things like ^M, etc. for ease of viewing

tr -d '\15\32' < /var/log/foo/temp > /var/log/foo/temp2;



# force it to lowercase

cat /var/log/foo/temp2 | tr -t '[:upper:]' '[:lower:]' > /var/log/foo/foo$dater;



# clean up the temp files

rm /var/log/foo/temp;

rm /var/log/foo/temp2;

I've checked the permissions to make sure the directory was writeable, which it was. And, as stated before, it works perfectly if you execute it manually. Just, for some reason, when it runs as a cron job, the resulting file (/var/log/foo/fooJan-02-2005) is empty as can be.

I'm running on a slack 10.0 box, with bash as the shell of choice. If you need any other information, let me know. Any help would be extremely appreciated. I've been mulling over this for about three weeks so far, and I'm getting worse about forgetting to run this thing manually each morning. :P

Quote:

# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null. We'll do this here since these jobs should run
# properly on a newly installed system, but if they don't the average newbie
# might get quite perplexed about getting strange mail every 5 minutes. :^)

If you look at root's crontab, you'll find that output is directed to /dev/null.

EDIT: ** Please ignore. I didn't read your post carefully. **

Ah... that's right.

I knew it would end up being something stupid I'd overlooked. I'll fix that and we'll see if it fixes it. Thanks!

No, I don't believe that this solves your problem. At best the redirection to /dev/null hides an error message that would have been mailed to you about the problem. I think it's a permissions problem or a PATH problem. Please check.

Permissions are right. I can say that much for certain. I've re-checked that countless times.

As far as the path being wrong, I don't see how that could be a problem if it runs properly when executed manually.

I thought you might have a point with your post about the /dev/null bit. I thought the > in...

Code:

tr -d '\15\32' < /var/log/foo/temp > /var/log/foo/temp2;

... might qualify as output. Is that not the case?

At any rate, my initial tinkering didn't work because I missed a stupid little something, so the script didn't even run last night. I fixed that, and I'll see in the morning if it works this time.

You might want to leave the temp files around to see what they contain...
I noticed you have this:
# clean up the temp files
rm /var/log/foo/temp;
rm /var/log/foo/temp2;
Comment them out and then check to make sure that /var/log/foo/temp contains what you expect it to after the script runs.

Other questions...
Why do you run one this way:
tr -d '\15\32' < /var/log/foo/temp > /var/log/foo/temp2;
and then turn around and do this?
cat /var/log/foo/temp2 | tr -t '[:upper:]' '[:lower:]' > /var/log/foo/foo$dater;

couldn't you do this:
cat /var/log/foo/temp | tr -d '\15\32' | tr -t '[:upper:]' '[:lower:]' > /var/log/foo/foo$dater;

Sorry about the delayed response. I've been too busy to even look into this for a couple days.

The main reason for separating them was for troubleshooting purposes, so I could look at the temp files as mentioned above, though I'll probably combine the commands as you suggested once it's... well, working.

I'm going to comment out the rm's and see how that goes in the morning.

Thank again for the help guys.

Actually no.

No matter what I do, there aren't any temp files created.

At least that establishes WHERE the problem lies. Just no idea why.

Just an idea...
Change /var/log/foo/whatever to /tmp/whatever
Not all users can write to the /var/log directory.

Hmmm...

But if it didn't have permission to write the temp files, how is it still writing the dater'ed files?

Got this working through a cron job:

Code:

# get the date, for the title

dater=`date +%b-%d-%Y`;



wget --tries=0 --retry-connrefused --output-document=/tmp/foo_$dater http://192.168.84.9/index.html



# remove the stupid windows formatting things like ^M, etc. for ease of viewing

tr -d '\15\32' < /tmp/foo_$dater > /tmp/temp2_$dater;



# force it to lowercase

cat /tmp/temp2_$dater | tr -t '[:upper:]' '[:lower:]' > /tmp/foo_$dater;



# clean up the temp files

rm /tmp/temp2_$dater;

Just as an idea, I'm going to try to have the wget write to /tmp and have the cat commands pull from there...

Code:

# get the date, for the log title

dater=`date +%b-%d-%Y`;



# pull the remote file

wget --tries=0 --retry-connrefused --output-document=/tmp/tempfile http://www.fakedomain.com/test.txt;



# clean it up

cat /tmp/tempfile | tr -d '\15\32' | tr -t '[:upper:]' '[:lower:]' > /var/log/foo/foo$dater;

I don't see how it could have any affect, but it's worth a shot. I can't believe it's taken me this long to actually get this working...

Gah. No dice. Still creates the empty dated file.

I'm gonna tinker with this some more, but in the meantime, I'll have the log reading script execute the cron script if the dated file is empty.

So does the /tmp/tempfile have anything in it?