Thanks guys!
I tried 1 <command line> too, to run every first minute of the hour. Not working. Is there any chance that my entry is not loaded in the to memeory?
I dont think I have the permission to install anything...
Starting a Cron job
How did you edit the crontab? Did you edit the crontab file directly or did you use crontab -e ? If the former I think there can be some problems (I've never tried it, I've always payed attention to the warning against it) 
HTH
Bubble
When your script runs from crontab, does it either have an evironment (eg a PATH) or have you specified full paths for all your commands (like "/bin/cd" instead of "cd")? I know many systems don't give you any environment except while in a shell so be sure you've checked for that.
Edit: and unless Solaris is really odd (which it often is), you shouldn't have to "reload" cron or worry about editing the cron file directly.
I tried crontab < /temp/cronjobs
where /temp/cronjobs has the updated cronjobs with my entry.
I have tried crontab -e too
Both saves the file but only my entry is not running. Others running as usual.
When I save the cron job file, it should give me a message saying cron jobs has been modified right? Cos I didn't get that msg
I gave the full path to my shell script, I didn't use any environment variables and I am not allowed to edit any .profiles neither...
My colleague told me she restarted something when she edited the file. She can't seem to remember what it cos she did it ages ago...
Originally posted by illusion
Thanks guys!
I tried 1 <command line> too, to run every first minute of the hour. Not working. Is there any chance that my entry is not loaded in the to memeory?
I dont think I have the permission to install anything...
when I have a cron job I want to run every 15 minutes, I'll set it up like this:
/15 * /path/to/script
also, do a crontab -l, is your new cron job showing up in the list?
- keith
Yes it does show up in the crontab -l
May be I should 2> error.txt on the entry?
My shell script is already outputing error tho...that is why I thot it wasn't necessary to put it in the cron job...
You could try putting something really simple in the crontab just to check it's running.
* echo "Hello" > test_output
Bubble
3 months later
I found the same problem under Solaris 9. To clarify all in advance:
The cron is working fine in general, all the scripts have absolute paths. The scripts rune fine from free hand, even if called from outside the working directory. All the file permissions seem OK. My script has output redirected into file (but the cron job itself - hasn't). So I started a war. I wrapped the php script in other shell script-didn't work. I called a php script directly putting #/usr/php as the path to interpreter in the first line of the script - didn't work. I inserted the direct call to php with my script into crontab-didn't work. I recompiled php to add CLI support-didn't work. I wrapped php call in a C program, (spawnle), compiled and ran. By hand-yes, by cron-no. My program ran but the php call was rejected - as if the process couldn't be loaded. I looked in php logs to find out what's wrong and found out that there is no trace of executing my srcipt at all. The cron logs (/var/cron/log AFAIR) show that the job execution failed but give only some error number which I'm unable to decode.
What I suspect therefore is that php itself cannot be loaded because the system cannot find the dynamic libraries required to run php. I don't know what is the user who runs cron jobs and if it is root (as in my case) - is the environment (showing the libraries locations (?)) loaded or not. Maybe adding "su - " at the beginning of the script could help? I'm not so tough Solaris guy to answer all this. Next week I'll check this, but maybe somebody will be faster...
Note that due to some bad communication under Solaris you cannot edit crontab: neither by crontab -e nor using vi - when you are connecting by ssh (what most of us do). It just rejects your jobs. Use telnet if you can or a terminal console. There is a workaround by setting some sshd variable: you may find it IN THE NET...
Cheers
Indeed it's the environment problem
See:
for detailsExperts Exchange
TTB
there are several different cron daemons out there which have some subtle differences in the crontab syntax and where they expect the crontabs
man crond /might/ give you info on which version is installed on your system...also note that '*/15' doesn't work with all of them