Program can not be run in the cron environment

[arking1981]

Dear everyone,

I don't understand why this happens.
I have a script with a commnand called dmcutil, a binary developped by us. I can run it mannually, no problem.

But when I want to run it periodically, I added the script into the cron job. What astonished me is the dmcutil never runs when the script was designed as a cron job.

I tried to put the command directly into cron enties like:
crontab -e

...
5 * * * * dmcutil >> /tmp/test.log
...

It was never invoked.
I don't what happens. Can anyone light me up? It will be appreciated.

Best Regards
Kang

[arking1981]

I want to add more information.

Part of the scripts can be run in cron environment, only the command dmcutil can not be run.

The system and the binary:
s7dmc # uname -a
HP-UX s7dmc B.11.11 U 9000/800 3617756966 unlimited-user license
You have mail in /var/mail/root


s7dmc # file /opt/dmc/bin/dmcutil
/opt/dmc/bin/dmcutil: ELF-64 executable object file - PA-RISC 2.0 (LP64)


Thanks
Kang

[arking1981]

sorry not to compose all the information in one message. Here below is the results in /var/adm/cron/log

> CMD: /opt/dmc/bin/dmcManage.sh
> biadmin 2163 c Tue Oct 19 01:25:00 WAT 2010

Seeming no error for executing this cronjob.

Thanks
Xie Kang

[TTr]

What does the dmcutil do as far as tty i/o?

[Aneesh Mohan]

Try with complete path.

5 * * * * /opt/dmc/bin/dmcutil >> /tmp/test.log

Aneesh

[arking1981]

Dear,

What do you exactly mean?
dmcutil is a bindary developped by us to manage a software. what do you mean tty i/o?

Thanks

[James R. Ferguson]

Hi Kang:

> what do you mean tty i/o?

TTr is asking if your executable uses the terminal to do I/O. If you attempt to read from STDIN (file descriptor 0 which is normally the initiating terminal), then under 'cron' unless you have redirected from a file, no terminal exists and the crontask fails.

You might try something like:

5 * * * * dmcutil < /dev/null >> /tmp/test.log

Regards!

...JRF...

[arking1981]

Re: Try with complete path.

5 * * * * /opt/dmc/bin/dmcutil >> /tmp/test.log

Aneesh

Dear Aneesh,
I tried your suggestion before, no effect.
1,2,3,4,5,10,12,13,14,15,16,19,17,18,35,40,45,50,52,53,55 * * * * /opt/dmc/bin/dmcutil >> /tmp/xk/tdmc.log
And an error with rc=137 was reported
> CMD: /opt/dmc/bin/dmcutil >> /tmp/xk/tdmc.log #/tmp/xk/ttDMCUtil
> biadmin 1141 c Sun Oct 24 14:52:00 WAT 2010
< biadmin 1141 c Sun Oct 24 14:52:01 WAT 2010 rc=137



I think there is not too much difference. As you can find the complete path is recorded in the cron/log:
> CMD: /opt/dmc/bin/dmcManage.sh
> biadmin 2163 c Tue Oct 19 01:25:00 WAT 2010
dmcutil is invoked by dmcManage.sh. However, there is a little difference, when executed in the above script, no rc=137 was reported.

Thanks
Kang

[SoorajCleris]

Hi Kang,

I have seen scripts fails when it runs as cronjob, but it runs in command line.

The only problem is the environement.
could you please export the environement in the job and check the change?

regards,
Sooraj

[Bill Hassell]

Your script works from an interactive shell because you have a customized environment. cron does NOT have this environment. All scripts that will be run in cron or batch or at must have everything defined, things like $PATH and other application environment variables. To see all the errors, turn on tracing in your script:

#!/usr/bin/sh
set -x

NOTE: the first line of all your script must start with the interpreter line so the correct shell will be run. This must be line 1 in your script. Then test the script using at:

/opt/dmc/bin/dmcManage.sh 2>&1 | at

[Horia Chirculescu]

>dmcutil is invoked by dmcManage.sh. However, there is a little difference, when executed in the above script, no rc=137 was reported.

Do you mean that starting dmcManage from cron is working as expected?

5 * * * * dmcManage.sh >> /tmp/test.log
works?

If this is the case, then take a look at dmcManage.sh script. Copy dmcManage.sh as dmcutil.sh and comment out in this file the other calls (except for dmcutil). Keep the defined shell and environment. Do not forget to chmod a+x the script.

Maybe post here this script.

Best regards
Horia.

[Dennis Handly]

>I added the script into the cron job

I don't see a script, I see an executable. Which is it? dmcManage.sh or dmcutil?

>when executed in the above script, no rc=137 was reported.

You are getting signal 9, SIGKILL. Have you exported LD_LIBRARY_PATH to the proper shlib paths?
What's in /tmp/test.log?
Did you get a mail message with the error?

[Viktor Balogh]

>dmcutil is invoked by dmcManage.sh. However, there is a little difference, when executed in the above script, no rc=137 was reported.

If you expect an output from your script, it should have been sent to the user as an email. (Unless STDOUT/STDERR was redirected to a file)

[Kapil Jha]

2 things

1) what does /tmp/test.log says now.
2) try
/usr/bin/sh /path/to/dmcutil 1>/tmp/stdout 2>/tmp/stderr

and then check what does these 2 files says.

BR,
Kapil+

[Satish Chalapati]

Dear Kang,

Is there any thing to do with .profile?


I have faced this problem when ever environment variables are present in my logic. So i used to call them before the script in the crontab and it used to get executed.

for e.g one of the issues i have faced is with oracle programs. Then i have set the environment variable of ORACLE_HOME in the script and it worked..

[arking1981]

Dear Sooraj Cleris,Dennis Handly,Kapil Jha and everyone:

Yes you are right, it is made by the different environment. The LD_LIBRARY_PATH is not set:
/usr/lib/pa20_64/dld.sl: Unable to find library 'libCDR_pa64-hpux.0'.

Can you please kindly tell me how to set the environment in a cron job?

Thanks in advance.
Kang

[arking1981]

Dear everyone,

I am asking if there is a way to import all env from the parent environment.
I hope I don't have to use many set command in the script. I am not lazy but afraid I wll miss something.

Best Regards
Xie Kang

[James R. Ferguson · Accepted solution]

Hi Kang:

> Can you please kindly tell me how to set the environment in a cron job?

If you profile contains the necessary environmental variables, you can "source" (read) that as the first step of your crontask. A common problem with using the profile, however, is that the standand HP-UX '${HOME}/.profile' contains terminal interactive commands like 'stty' and 'tset'. Since a cron'ed task isn't interactive (associated with a terminal) unless you condition-out this profile code, you get messages of "Not a typewritter" when you cron your task.

A very clean way to handle environmental variables that you want to use in scripts, is to create a separate file of them that you can be "sourced" (read) whenever necessary. By example, you could do:

# cat /home/arking1981/env
#!/usr/bin/sh
export PATH=$PATH:/home/arking1981/scripts
export SHLIB_PATH=/home/arking/1981
export TZ=UTC

To use this, do:

. /home/arking1981/env

...Note the dot character (".") followed by a space (blank) followed the absolute path of the file you want to read "into" your script. This is what is called "sourcing" a file.

# . /home/arking1981/env; /home/arking1981/scripts/dmcutil

...or in a crontab:

5 * * * * ./home/arking1981/env;/home/arking1981/scripts/dmcutil >> /tmp/test.log

The file of your variables can also be sourced at the end of your login profile too. Thus, only ONE copy of variables needs to be maintained.

Regards!

...JRF...

[Dennis Handly]

>JRF: #!/usr/bin/sh

No need for this in script fragments that you can only source. (Unless this helps your editor.)

[James R. Ferguson]

Hi:

> Dennis: >JRF: #!/usr/bin/sh
No need for this in script fragments that you can only source. (Unless this helps your editor.)

True. My personal preference is to include the interpreter line as documentation. Of course, in fairness, I only use POSIX or Korn shells so the syntax of the included material should be compatible in either case ;-)

Regards!

...JRF...

[Dennis Handly]

>JRF: I only use POSIX or Korn shells so the syntax of the included material should be compatible in either case ;-)

That's not relevant. If you source something, you use your current shell. The #! is just a comment. You also can make the file non-executable so it is never executed as a script.

[James R. Ferguson]

Hi :

> Dennis: > JRF: That's not relevant. If you source something, you use your current shell. The #! is just a comment. You also can make the file non-executable so it is never executed as a script.

I am quite aware of both statements. When I said that, "I only use POSIX or Korn shells so the syntax of the included material should be compatible in either case" I meant that I include the interpreter line as documentation for the body of the included file's contents if/when a human reads the file's contents. If I was running the standard POSIX shell but attempted to source a file containing 'setenv' statements from your favorite C-shell, the POSIX shell is going to complain loudly when it encounters the 'setenv' statement (not the interpreter line).

Regards!

...JRF...

[arking1981]

Dear all,

Thanks for your great help.
Now my cronjob is working.

I am closing this thread now.
Apologize for replying so late, just too busy.

Regards
Kang

[arking1981]

Solved based on the comments