Hi,
on AIX server 2 7 00CDDA774C00
Any of the following lines in crontab do not execute:
05,10,18 * * 1-6 . ~/.profile 1>/dev/null 2>&1 ; ksh /home/u1/test_tablespace_chck/checktbs.ksh 1>/dev/null 2>&1
05,10,18 * * 1-6 ksh -x /home/u1/test_tablespace_chck/checktbs.ksh >/dev/null 2>&1The script /home/u1/test_tablespace_chck/checktbs.ksh works fine when run manually on commande line.
Any help?
Thanks.
Redirect the output to a file; instead of /dev/null have /tmp/cronjob.out
Then look at the file.
Just seeing that your schedule counts 4 fields where it must be 5. Did you miss the first (minute) field?
* 05,10,18 * * 1-6 ...
On top of the above suggestions, did you have a look at the cron logs?
If I have my little idea, I would be very interested to know what is found in the logs...
As @MadeInGermany says, if you missed out a field, how did you do that? Remember that if you are entering cron jobs into crontab by direct editing then the job(s) may not execute for up to 24 hours unless you stop and restart the cron daemon. You should use the provided tools to schedule cron job(s).
If I were you, @big123456 I would also check all your paths.
For example, you might have written this to work for a user called big123456 but your crontab might be running as root. I am sure you know that this:
~/.profile 1
.... is not the same as this...
~/.profile 1
Many people make this kind of mistake. They write a script in one environment (under one user's profile or with certain env vars) and they execute the same script in a cron file as a different user, for example, root.
This also applies to any paths inside this script and all included scripts:
/home/u1/test_tablespace_chck/checktbs.ksh
Are you using full paths inside the script above?
Also, as other have mentioned, when debugging, you should not redirect the output to /dev/null !
You need to see the output @big123456 , so better to send it to a file, for example:
ksh /home/u1/test_tablespace_chck/checktbs.ksh 1 >> /tmp/my_checktbs_ksh_output.txt
This is how we debug things. We / You / Anyone needs to see the output and so sending it to /dev/null is not going to provide you any clues 
If you are still having issues, you can have your script send the env to a log file, like this (not sure what is the env and id command in AIX (now, I'm on macos), but you get the idea):
id >> /tmp/debugging_my_environment.txt; env > /tmp/debugging_my_environment.txt
In other words, you have a lot of visibility into every step of your processes, but you have to expose these steps before you debug them. We cannot read your script, your environment, and we do not know what uid you are running; because you did not share that; and since you send all your output to /dev/null, you cannot see this information either.
There is no need to guess as the answer lies right in front of you if you "open" your code so you can see what the script is actually doing.
HTH
I am not clear what OS distro you are on. My crontab editor throws errors on both your commands, and refuses to save the crontab file until the five timing fields are correct on every line:
$ crontab -e
crontab: installing new crontab
"/tmp/crontab.UJ3MaP/crontab":44: bad day-of-week
"/tmp/crontab.UJ3MaP/crontab":46: bad day-of-week
errors in crontab file, can't install.
Do you want to retry the same edit? (y/n)
It is usually best to check the time parameters separately to the command. My usual start would be (e.g. today at 13:43):
*/3 14,15 6 * * date >> /tmp/cron1.log
Watch the log with tail -f /tmp/cron1.log, ensure it tick every three minutes. Mess a little with the time options to see the effect.
Obviously, you tailor those time specifiers to be effective immediately, and also (equally important) that they do not trigger unexpectedly (day of week, and day of week plus day of month, are tricky).
Percentage (as when you use date "+%H:%M:%S" within the command) are a mystifying special character.
You can also check your final time specification, by leaving it active for a day or two, and checking all the times it ran. You can do this in parallel with your testing of the script itself. Typically, I run jobs under development on a 5-minute cycle, and keep a clock open so I can save latest edits just before the schedule runs.
When you are confident that the triggering happens, replace the date command with a single call to a simple script, and make sure that outputs too. Initially, have it ls -l each file you depend on, so you know the paths are right. Log the env too.
My personal preference is never to use more than one simple script call within the crontab: you don't really know what shell or environment cron is going to supply, so that script needs a shebang and all the debug you can think of. It is also far more obvious to source profiles in a script, rather than in the crontab command.
This reply is all about getting the timer constraints right. @neo has fully covered the issues stemming from environment, profile and directory errors (which all result from the basic cause that the cron daemon does not log in your user when it runs your commands).
This is a very good idea.
Was going to suggest it, however, my intuition tells me the issue is not the crontab entry, but the path(s) and env used.
After all, he could just test it like this, if he wanted to just check to see if cron was executing every (in this example) five minutes.
*/5 * * * * ksh -x /home/u1/test_tablespace_chck/checktbs.ksh >>/tmp/my_great_debugging_file.log
I agree that this is also a great check if you want to wait a long time for test results:
*/3 14,15 6 * * date >> /tmp/cron1.log
Over the years here on unix.com, generally crontab issues are almost always related to either (1) paths or (2) envs (or both).
Most people overlook (1) paths, (2) permissions and (3) env vars (repeatedly) on unix-like systems (for some reason).
Of course, nothing wrong with checking cron as suggested by Paul as well. It's good to check everything.
Note that */3 ("every 3 starting at 0") does not work on AIX.
You must use 0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57
Thanks to all.
As said above it was a problem of complete path. In scripts executed by cron should indicate complete path for each directory.
Like this my problem is solved.
Regards.
Welcome.
Remember: