Do you find the log? There is no absolute path to the log file opn_amt_gestores_credito.log so if this is a root cron the log will be created in the root directory.
Also look in /var/adm/cron/log to see if the cron ran. Look in unix mail for the owner of the crontab to see if the job produced any error output.
Is there any entry at all for the 13:00 run in the cron log?
grep "report" /usr/adm/cron/log
If the script did run, please post the contents of the script because there must be something funny in it.
If the cron did not run at all, is there anything relevant in /usr/adm/syslog/syslog.log ?
Do you have any other symptoms like commands mysteriously not working? Has the kernel been tuned since the system was installed?
This is not getting us along too well. You do know that crond does NOT create environment variables for a user like login does. This will mess up a lot of otherwise good code.
So the first problem is since you are not getting errors from your redirection:
where is the log file? does it exist - post the output of:
find / -name opn_amt_gestores_credito.log -exec ls -l {} \;
Next PLEASE post your code, something odd is definitely going on.
# List of cron entries
crontab -l report
# Check whether someone is changing this file
ls -lad /usr/adm/cron/cron.allow
# Check what's in it at the moment (during the day)
cat /usr/adm/cron/cron.allow
Please post the output from this command while logged in as root:
It should be about 50 lines long.
/usr/sbin/sysdef
And this one:
sar -v 2 10
And the one we asked for earlier:
ls -lad /var/adm/cron/cron.allow
cat /var/adm/cron/cron.allow
When you posted grep report /usr/adm/cron/log were all the other night time jobs containing the word report missing too?
What's the timestamp on the cron log?:
In the kernel nproc (maximum processes running on the system) is quite low at 4200 but maxuprc (maximum processes for one user) is high at 3682 . The sar shows that you have some leeway. It's not that.
If cron itself is sick we would expect messages like "queue max run limit reached" in /usr/adm/cron/log or other errors in /usr/adm/syslog/syslog.log and possibly in /var/mail/root .
Because the other jobs for account "report" ran we can eliminate expired password.
This is quite a mystery.
My best guess is that this is a HP-UX Trusted System and the account report has been restricted to certain hours of operation which don't include 13:00 .
Probably a silly question, but did you originally have just the 01:00 definition?
If so, did you use crontab -e to edit the file, or did you just edit the file down /var/spool/cron/....... somewhere?
If you did then the cron deamon will not recognise the update.
A forced clock change with date -u can also confuse cron and you may need to stop/restart it.
If you feel that you should stop/restart it because of either of the above, check in /etc/inittab to see if it has been coded as a respawn process. I have this on AIX, but HP-UX seems to have it started with /sbin/rc2.d/S730cron. You would be best to stop start with this script if this is what you have too. Run it as root:-
# sh /sbin/rc2.d/S730cron stop
# sh /sbin/rc2.d/S730cron start
Of course, if this is not the case, please ignore me.