Cron job won't run

[nerri]

I have written and saved a crontab but it doesn't run. It is :

25 * * * * ./myprogram.pl > ./cron_log

Is there a way to see what is going on?

 

[mbrooks]

Use absolute paths.

M. Brooks

http://mbrooks.info

 

[nerri]

Are those the paths in /etc/default/cron?

 

[Annihilannic]

What he means is, instead of specifying ./myprogram.pl > ./cron.log, specify the full path to it, e.g. /home/mydir/myprogram.pl > /home/mydir/cron.log.

Annihilannic.

 

[Annihilannic]

Incidentally, it *should* have worked anyway if myprogram.pl is located in the crontab owner's home directory, because that is where "." will refer to when a job is run from cron.

Annihilannic.

 

[KenCunningham]

Also make sure that any PATH variable operational when you run the script interactively is replicated early within your script (export PATH=</yada/yada>.

I don't mind people who aren't what they seem. I just wish they'd make their mind up.

 

[nerri]

I had already tried it with the absolute paths, which didn't work either. I tried changing the permissions to all users/all access, which I don't like, but it worked, but I don't understand why that would have changed it. The crontab is in my home directory. I was under the impression cronjobs were run as root. Any light on the subject?

The problem now is that the files I want are being created, but not populated. I have discovered that this is due to the inability to open one of the files which bombs the program out. This file is in the same directory as my crontab and has all users all access permissions. By the way...I am installing my crontab this way:

crontab my_crontab

[\code]

Normally I use crontab -e to edit and install, but for some reason this command will not work on my SA's computer for him to see what I have written in there.

 

[Annihilannic]

What happens when you use crontab -e? Do you get a prompt which is just a number? If so, you are probably using the ed editor by default. If you prefer to use 'vi', do the following before crontab -e

[tt]EDITOR=vi
export EDITOR[/tt]

Even root has to have execute permissions on a script to execute it. You don't have to give everyone write access, just chmod 755 should do.

cron jobs don't all run as root, they run with the same UID as the owner of the crontab in question.

Annihilannic.

 

[mikejordan]

I've had problems with cron scripts when they run from the command line, because I'm in a korn shell, but cron uses a bourne shell. Putting "#!/bin/ksh" at the top of the script fixes it. But I'm not sure if this applies to perl. Maybe.

 

[KenCunningham]

That's a good call Mike. perhaps #!/usr/bin/perl ?

I don't mind people who aren't what they seem. I just wish they'd make their mind up.

 

[nerri]

Sorry for my long silence. Halloween came and at the same time my workload shot up. Anyways, I managed to figure out that the cronjob is running (SA will not give me read access to the log so I kind of have to be creative about debugging), and I found the line of code that its barfing on. This is actually a require statement. I make three require statements, using the full path, and two are fine and it chokes on one of them. All three files are in the same directory and called the same way. All three have the same execute permissions. Any suggestions for this one?

Anni, I use emacs. That's my prefered editor and I bugged the SA till he put it on there. He's done something to the VI that makes it completely unusable for me.

Ken, I'm not sure what the following means...could you please elaborate?

Also make sure that any PATH variable operational when you run the script interactively is replicated early within your script (export PATH=</yada/yada>.

 

[nerri]

Do you think this is more of perl issue and I should jump over to that forum?

 

[Annihilannic]

Would be worth a try I'd say.

Annihilannic.

 

[KenCunningham]

Nerri, sorry I've been off, so this is the first opportunity I've had to get back to you. Hopefully you've now sorted your problem, but my reference to the PATH variable meant to include within the script a line:

export PATH=<path as seen when issuing an echo $PATH statement as the user in question>

Hope this now makes sense.

I don't mind people who aren't what they seem. I just wish they'd make their mind up.