iloop2
asked on
Difference between cron and shell in passing variables to a java process
I have a cron job that calls a shell script to monitor a process and if not running restart it BUT one of the variables is not passed if called from cron but is if the shell script is run directly.
Details:-
OS is RHEL3.
cronjob is defined for a user (user1) as:-
0,15,30,45 * * * * /home/user1/monitor.sh
/home/user1/monitor.sh is:-
#!/bin/bash
#
#
PATH=$PATH:/usr/java/j2sdk
UNITY_OPTS1="-Dlog4j.confi
UNITY_OPTS2="-DFile.encodi
user=user1
process=java
if pgrep -u $user $process >/dev/null; then
check=okay
else
echo "`date` user1 down" >> /home/user1/logger
echo "`date` user1 down"
cd /home/user1/
java -cp <jar stuff> "$UNITY_OPTS1" "$UNITY_OPTS2" <org stuff> start &
echo "`date` user1 restarted" >> /home/user1/logger
fi
The problem variable is -DFile.encoding=UTF-8 defined in UNITY_OPTS2 it is NOT activated when the shell script is call from cron but YES if run
as /home/user1/monitor.sh.
Notes:
There is no difference if the -DFile.encoding=UTF-8 is put dirrectly on the java command or passed as variable as above..
<jar stuff> and <org stuff> refer to additional data that I've removed for clarity.
Everything works fine if -Dfile.encoding=UTF-8 is not used so I believe the script is okay just for that one variable there is a problem..
Details:-
OS is RHEL3.
cronjob is defined for a user (user1) as:-
0,15,30,45 * * * * /home/user1/monitor.sh
/home/user1/monitor.sh is:-
#!/bin/bash
#
#
PATH=$PATH:/usr/java/j2sdk
UNITY_OPTS1="-Dlog4j.confi
UNITY_OPTS2="-DFile.encodi
user=user1
process=java
if pgrep -u $user $process >/dev/null; then
check=okay
else
echo "`date` user1 down" >> /home/user1/logger
echo "`date` user1 down"
cd /home/user1/
java -cp <jar stuff> "$UNITY_OPTS1" "$UNITY_OPTS2" <org stuff> start &
echo "`date` user1 restarted" >> /home/user1/logger
fi
The problem variable is -DFile.encoding=UTF-8 defined in UNITY_OPTS2 it is NOT activated when the shell script is call from cron but YES if run
as /home/user1/monitor.sh.
Notes:
There is no difference if the -DFile.encoding=UTF-8 is put dirrectly on the java command or passed as variable as above..
<jar stuff> and <org stuff> refer to additional data that I've removed for clarity.
Everything works fine if -Dfile.encoding=UTF-8 is not used so I believe the script is okay just for that one variable there is a problem..
ASKER
gnudiff thanks for the thoughts:
1) Yes if I do that in the logger file is "Fri Aug 27 14:13:00 BST 2004 user1 restarted w/ -DFile.encoding=UTF-8"
NB it also fails if -Dfile.encoding=UTF-8 is put directly on the java command line (was my initial method).
2) No problem asking, it is the kind of error that is very common, but I have checked multiple time and cleared the cron for the user calling the script, changed the time and the message echoed to the logger file to ensure it is the correct version. New install of OS etc so a clean setup to work with anyway.
Not sure whether it is a cron/shell or Java issue is the main problem in determining a solution, although in terms of Java it works when /home/user1/monitor.sh is called directly hence the thoughts on it being a cron/shell issue.
Thanks
1) Yes if I do that in the logger file is "Fri Aug 27 14:13:00 BST 2004 user1 restarted w/ -DFile.encoding=UTF-8"
NB it also fails if -Dfile.encoding=UTF-8 is put directly on the java command line (was my initial method).
2) No problem asking, it is the kind of error that is very common, but I have checked multiple time and cleared the cron for the user calling the script, changed the time and the message echoed to the logger file to ensure it is the correct version. New install of OS etc so a clean setup to work with anyway.
Not sure whether it is a cron/shell or Java issue is the main problem in determining a solution, although in terms of Java it works when /home/user1/monitor.sh is called directly hence the thoughts on it being a cron/shell issue.
Thanks
Try printing out the environment from the script and check for differences: set >> /home/user1/logger
Java may not be able to find the necessary libraries or files for UTF-8. Since crond is started from the startup scripts, the environment parameters may not be set (correctly) for java to run properly.
You can also try to kill crond, run it again from the command prompt and see if the script works. If it does, it's definitively an environment problem.
Bob Gunzel
Java may not be able to find the necessary libraries or files for UTF-8. Since crond is started from the startup scripts, the environment parameters may not be set (correctly) for java to run properly.
You can also try to kill crond, run it again from the command prompt and see if the script works. If it does, it's definitively an environment problem.
Bob Gunzel
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ramazanyich - thank you that looks very promising, do not have access to the server until tomorrow but will try that then.
Do you hav a URL for the info. from SUN it would be useful.
Do you hav a URL for the info. from SUN it would be useful.
ASKER
It worked using the environment variables you suggested ramazanyich, thanks I was under the impression that Dfile automatically set all of them but in this can from cron I guess not. Would of taken me an age to figure that out. If you have the link to SUN detailing it would be very useful..
Thanks..
Thanks..
We had the same problem on our Solaris box. I remember that I found page which said that file.encoding property is readonly, but I don't have that link anymore.
echo "`date` user1 restarted w/ $UNITY_OPTS2" >> /home/user1/logger line, - does it print out the correct value and prefix when run via cron or shell?
2. Forgive me for asking, but are you entirely positive that you do call the same script from cron and from shell; or perhaps you have another cron entry that calls an older version of the script at another time, somehow? It might sound strange, but these kinds of errors do happen sometimes.