Difference of running scripts manually or with a cronjob

Question

I have a PHP script that I want to run every 10 minutes, going through database records and creating/editing movies through MEncoder. I've set up cron job to accomplish this, but it doesn't work very well.

I have my PHP script, call it document.php. I also have a bash script (document.sh) to call this PHP script;

#!/bin/bash php document.php 

Now comes the weird part: When I manually run the bash script everything works great - the movies are created or edited just the way I want them - but when I let the cron job run the bash script every 10th minute the movies are corrupt. They have some frames in them, though. I have no clue how this can happen. I've checked the permissions and file paths and everything looks fine. Does the cron job kill my process? Does it have a time limit (it takes roughly 1-2 minutes to run MEncoder through the files)?

Hope someone can provide an answer - this really bugs me and deadline is near.

I'm running Ubuntu Server with the latest updates and the latest MEncoder from the repo.

Best regards, Björn

Answer 1

Running from cron doesn't pull in your shell configuration files (~/.bashrc or ~/.profile or /etc/profile) Is it possible there are environment variables defined there that are affecting your job? Try sourcing your profile files manually at the start of your script. (. /path/to/profile)

Answer 2

That's a very common problem with cronjobs--you simply cannot assume your environment variables, paths, etc. What I like to do is to have a cronjob that does "set > /tmp/set" so you can see exactly what you're going to have from the point of view of the cronjob. This way you can compare the assumptions your script makes, and what adjustments need to be made.

Answer 3

My simple solution is to call the php file with LYNX Assuming you have an http server running

lynx http://127.0.0.1/document.php

Answer 4

There shouldn't be any time limit - at least by default, not sure about this distro. Do you receive the cron email? If not, redirect stdin/stdout to a file and see what the process says.

your-cmd > filename.txt 2>&1 

Answer 5

As others have stated, the number one most likely issue is the lack of some environment variables. If that's not it, the other possiblity I can think of is: Are you sure the job only takes 1-2 minutes? if it takes > 10 (your interval for respawning it), you could end up with multiple runs trying to modify the same files, which could cause some of the corruption you mentioned.

Debugging cron is always... fun. first off, check root's email on that system; if the cron job put anything on stdout, it should be there. If nothing useful showed up there, you can make something show up there by putting some debug output into your script.