Cron jobs not executed for specific user

[Panagiotis Tzolio]

We have created some crontab jobs for a specific user.
We have noticed that none of them is executed any more as scheduled, whereas as manual commands are successful.

Even simple commands under this user's crontab (eg date) are not executed whereas under another crontab with same group and same shell are successful.

Restarting cron daemon does not have any result and
ps -ef|grep cron
shows
# ps -ef|grep cron
root 13824 13798 0 17:10:25 pts/1 0:00 grep cron
root 16891 1 0 11:35:35 ? 0:01 /usr/sbin/cron

Can you please advice on what the problem can be?

[Kapil Jha]

check in cron log what exacttly is happening.

Second you will have to tell how u scheduled the jobs...
crontab -e or crontab filename

BR,
Kapil+

[Michal Kapalka (mikap)]

hi,

you could use su - $user and all your defined crontab scripts could be running under root crontab.

mikap

[Panagiotis Tzolio]

In the cron log commands are referred but in real they are not executed.
In the past everything was working properly.

Is it possible that any cron job of this user is hanged and causes the rest of them not to be executed?

[Michal Kapalka (mikap)]

hi,

when you executing the script manually,

under which user and how ??

sh shell_script.sh

mikap

[Kanagaraj]

check /usr/lib/cron/cron.allow & cron.deny files are exist or not.

If cron.allow is exist then put the user entry & restart the cron daemon.

[Hakki Aydin Ucar]

I agree with D.Kanagaraj, check this out. cron.allow

[Panagiotis Tzolio]

The user is inside cron.allow.

Is it possible that any cron job of this user is hanged and causes the rest of them not to be executed?

[Hakki Aydin Ucar]

No , I do not think so that cron jobs will affect others belongs to that user.

You say cron.allow is OK then

What can you see when examine the logs related with your user:

more /var/adm/syslog/syslog.log
more /var/adm/cron.log

OR

cat /var/adm/cron.log | grep -i

[Hakki Aydin Ucar]

On second though; for test purpose :

try this with user root if you can afford it ?

and write here what is your exactl line in cronjob ?

crontab -e ?

[Panagiotis Tzolio]

You can find attached the cron log.
The problematic user is nmcman.
Does this give you any clue?

[TTr · Accepted solution]

The jobs are getting executed but are getting a killed with a ts=9 status. Look for yourself in the cron log
> nmcman 19468 c Mon Oct 12 12:00:00 EETDST 2009
...
< nmcman 19468 c Mon Oct 12 12:00:00 EETDST 2009 ts=9

The log entries are intermixed with log entries from other jobs so you have to pair the log entries approprietly. The ">" stands for a job start and the "<" stands for a job exit. You can see the ts=9 at the exit entry. That is a hard kill with a "kill -9" signal. Now a few things to check as to why the jobs are getting killed.
1. Yes in some cases a command will not run if a another commnad is still executing from before. This is true with commands that lock a file or depend another resource (such as a port or a pipe file or a fifo) which is in use by a previously executed command
Check with "ps -efu nmcman" to see what else is running by this user.
2. Check if you are hitting any system limits such as open files, flocks, user processes etc. Look at the /var/adm/syslog/syslog.log for any errors.
3. Did you recently convert to a trusted system?

You also have too many jobs running every minute. Is that really necessary?

[Hakki Aydin Ucar]

Yes, whenever you cron attempt to run it was immediately killed as TTr said.

Try (if you can use root) the same command with user root OR another user in cronjob:

as far as I can see also nmcman used another commands with this use and also got killed

[Panagiotis Tzolio]

Exactly!
The commands fail only for the specific user. All the others are working fine.

I will re-check cron and syslog logs.

[TTr]

You can also check if nmcman receives any email from cron regarding the killed job. See if there is anything else in the email.

You can add the -x c-shell flag to the crontab entry so that you get all the commands echoed as they are executed.

... csh -f -x /opt/mv36 ...

You can simplify his cronjob, why did he/she put /../ in there. It does not change anything, it just finds the command more directly.
... csh -f -x /opt/mv36/core/script/CK ...




Check

[Dennis Handly]

What OS version are you running?

I would suggest you not write cron scripts using the scummy C shell.
Unfortunately you have one entry: date >> /home/nmcman/test2.txt
that uses the posix shell and that aborts too.

One time when cron was aborting, it occurred due to a bogus value of TZ. What's the value for nmcman?

>TTr: The jobs are getting executed but are getting a killed with a ts=9 status.

Hmm, the last time I looked, kill 9 would be ts=137, 128+9.
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1287859
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1212499
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1287859
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1319191

[TTr]

> Dennis: ...kill 9 would be ts=137, 128+9.

Isn't the 128 offset used for the root user only?

[Dennis Handly]

>TTr: Isn't the 128 offset used for the root user only?

I'm not sure why wait(2) would treat root special?

[Dennis Handly]

>TTr: Isn't the 128 offset used for the root user only?

The 128 is used to indicate a coredump was produced. So you are correct, there was a kill -9.
SIGKILL is also also occurs when dld detects unsats. (Not sure how that happens with date(1).)

[Panagiotis Tzolio]

Let me remind you that everything was working properly also for this user and no cron job is executed any more as scheduled, whereas as manual commands are successful.

The OS is HP-UX version B.11.23 in a ia64 hp server rx6600.

What else can i check so as to find the root cause of the failure (ts=9)?

[Dennis Handly]

>whereas as manual commands are successful.

Do the following to make sure manual commands fail:
$ env -i PATH=/usr/bin:/usr/sbin:. sh

Now try your "manual" commands and see if they fail with signal 9.

>What else can I check so as to find the root cause of the failure (ts=9)?

Have you stopped and restarted cron?
Have you rebooted after this user started failing?

I suppose you could use tusc on cron to see what it is doing:
tusc -fp -ea -o tusc.out $(UNIX95=EXTENDED_PS ps -C cron -o pid=)

[Suraj K Sankari]

Hi,

Can you post the crontab -l and the script which is not executed.

Suraj

[mvpel]

Is the user's password expired by any chance? I've experienced Solaris no longer running cron jobs when someone forgot to change the root password before the maxage time in the /etc/shadow, perhaps HP-UX cron does something similar.

[Panagiotis Tzolio]

>Do the following to make sure manual commands fail:
$ env -i PATH=/usr/bin:/usr/sbin:. sh

Now try your "manual" commands and see if they fail with signal 9.

Can you please explain what this command does?

>Have you stopped and restarted cron?
Have you rebooted after this user started failing?

cron was restarted and server was rebooted without result

>I suppose you could use tusc on cron to see what it is doing:
tusc -fp -ea -o tusc.out $(UNIX95=EXTENDED_PS ps -C cron -o pid=)

Can you please explain what this command does and if we have to type everything (even these that are in parenthesis)?

[TTr]

> Now try your "manual" commands and see if they fail with signal 9.

> Can you please explain what this command does?

Can the nmcman user login to the server without any problems? After login can he/she execute the same commands from the cron job, by typing them on the unix command line?

You have not been giving answers to most of the questions that people have asked you here.