If I directly run the bellow code in terminal it is working perfect.
/usr/bin/java -jar /var/jboss-as-7.1.1.Final/standalone/email_linux/notification_18.jar
But when I set the same as a crontab in ubuntu server then it is not working.
*/3 * * * * /usr/bin/java -jar /var/jboss-as-7.1.1.Final/standalone/email_linux/notification_18.jar
Any one know why unexpected behavior?
The crontab task is executed under a different user from the one with which you are testing the call. JBoss depends on a number of environment variables, which are probably undefined in that context. So find out what that particular JAR needs from the environment and then add it into a shell script which you run from the cron task (instead of directly running java from cron).
Make sure that you have included the absolute paths in the source code if you are reading or writing to a file, even if the jar file and the reading file are in the same directory.
It is resolved after specifying absolute path
Related
I want to run JMeter test plans from a UNIX server where env variables for java is not set. Its a test server and I dont have access to set that. We have different JDK versions and all are sitting in directories. I need to run my JMeter TestPlans on this server. I went to JDK /bin folder and tired to execute the below command
$ {jmeter-path}/bin/jmeter -nt testplan.jmx -l testresult.jtl
but this says
./bin/java: not found
But if I do simple java -version it shows the version result.Is that something that JMeter needs specifically the java env variable set or it wont run ? I dont have permission to set and I want to run the testplan using the JDK/JRE from its directories. A help would be appreciated. Thanks in advance!
UPDATE:
I think I could work around this by editing the jmeter script file as suggested in the one of the comments. Since my requirement was running the JMeter from a specific server, I could achieve this by editing the JAVA_HOME variable value in the script.
JMeter looks for java executable in system PATH so you have 2 options:
Add bin folder of your JDK or JRE to PATH, something like:
PATH=$PATH:/location/of/your/jbk/bin && export PATH && {jmeter-path}/bin/jmeter -nt testplan.jmx -l testresult.jtl
Or if you have java in PATH just run ApacheJMeter.jar like:
java -jar {jmeter-path}/bin/ApacheJMeter.jar
You might also want to use jmeter.sh wrapper script instead of jmeter, it has some logic regarding java binary location
More information: Get Started With JMeter: Installation & Tests
The official JMeter Getting Started documentation says this:
To install a release build, simply unzip the zip/tar file into the directory where you want JMeter to be installed. Provided that you have a JRE/JDK correctly installed and the JAVA_HOME environment variable set, there is nothing more for you to do.
Based on the symptoms that you reported, I think that you have not set JAVA_HOME correctly. It should be set to an absolute path to your Java installation's top directory.
This question already has answers here:
cronjob does not execute a script that works fine standalone
(3 answers)
Closed 6 years ago.
I wrote a bash file in which I am executing java file, its working properly if I am executing it but when I am trying with crontab it is not ,please help.
this is my crontab :
*/5 * * * * /home/import.sh >/dev/null 2>&1
this is my bash file:
- me=$(date +%Y-%m-%d)
mkdir -p /home/importRequirement"$foldername"
{
java -jar ImportRequirement1.jar
java -jar ImportRequirement1.jar
}
2>importRequirement"$foldername"/log$(date +%Y-%m-%d-%H-%M-%S).txt
I have deleted the url.
When a script is intended to be started from a non interactive environment (cron or init), none of the usual goodies such as custom path or other environment variable are set.
The rule is:
ensure all the commands (except at most those in /bin and /usr/bin) use full path
ensure all required environment variables are set
If you use many scripts that way, you could build a setenv script that declares all environment variables and create ones for every command you use. Here it will contain (more or less):
export JAVAHOME=...
export JAVA=/path/to/java
Then you can use in your script:
$(JAVA) -jar ImportRequirement1.jar
but here again you should either have a previous cd to the expected directory or use absolute path of jar
The environment variables for cron jobs is not the same as what users get when they are logged in. Double check the environment variables you need to run your script (ie JAVA_HOME and PATH).
cron might not know with what to interpret your script, you might want to place
#!/bin/bash
on the first line of your bash script.
I have scheduled my job to run every day at 12:30 with this command:
30 12 * * * java -jar test.jar
It throws error:
/bin/sh: 1: java: not found
I tried to run this command: java -jar test.jar from shell and it worked just fine.
Now I don't understand. I would say it is happening because JAVA_HOME environment variable is not set, but then why it works from shell?
The error tells you that the shell could not locate the java binary to execute. This has nothing to do with the JAVA_HOME environment variable, but with the PATH variable which is consulted by sh to find any command.
When you run your task from cron, the shell did not receive the same initialization as your interactive shell where the command works for you. You'll equally find that JAVA_HOME isn't set there, either.
Your login shell environment is different from the one your cronjob has. Use envto print your environment.
Check the path on both -
Within cron (something like)
30 08 * * * env > ~/cronenv.
In your login shell just use env. Then compare the PATH variables.
As #Marko Topolnik already stated your PATH within cron obviously does not contain your java executables.
You can add a line into your crontab file that contains the path that you need:
# m h dom mon dow command
PATH=.....
You probably need something like this:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
You can also use echo $PATH to find out what you have in your regular environment and simply use that value.
Another option i tried is to use the path of the java installed.
Make sure java is installed with below command
java -version
Check the path of java installed
whereis java
provide the full path to run the app
30 12 * * * /path_from_prev_step/java -jar test.jar
This will also allow you to run this jar with different java portable version if the server has a older version installed.
I'm running Ubuntu 10.10 with open jdk and crontab. I made a neat little Java application that does some cool stuff and exported it as a runnable jar file. I can run it from the command line just fine, but I needed something that would run the file once every day. So I wrote in a cron job to run a shell script that would actually invoke the jar file. The shell script works fine when run on its own and it looks something like this:
#!/bin/sh
/usr/bin/java -jar /root/proj/CoolStuff.jar
Works perfectly. So I added this to the crontab:
23 14 * * * /root/proj/runScript.sh > /root/proj/log.txt 2>&1
This does not run perfectly. In fact, it doesn't run. log.txt will come out saying "Error". Pretty nondescript, right? I've checked my environment variables, nothing fancy there. Is there anything else I might be missing? Any ideas as to where to go from here? Is there any way I can run this script everyday with ease?
Check the execution permission on that file.
The cron is running with different permissions, not the one you got when logged in.
Also you try to access /root.
Try to relocate your script to another "non-root" directory.
See what the environment for you crontab looks like by commenting out your current /usr/bin/java .. and insert set on a line by its own.
Now from you command line do set > tmpEnvVarList.txt and compare with what you see in log.txt.
It's almost certainly that your .profile or .bash_rc (or other) is setting env vars that are not available to you crontab. You'll need to add . .profile etc to you script.
cbO's ideas are good too.
I hope this helps.
why the error occurs when i am starting the jboss server 6.0 ?
'findstr' is not recognized as an internal or external command,
operable program or batch file.
It looks like your PATH environment variable hasn't been set up correctly. Does this link help?
http://community.jboss.org/wiki/FindstrCommandNotFound
EDIT: are you sure that the JBoss startup batch script (usually in %JBOSS_HOME%\bin\run.bat) is picking up the PATH correctly? It might be running as a different user with a different PATH. Edit this script and add the line echo %PATH% before the first line that contains findstr. What output does this give you?
The only other place findstr is used (in jboss-6.0.0.20100721-M4 anyway) is in the service.bat script in the same folder as run.bat . Again, you could try putting echo %PATH% before the line in this script that uses findstr if the previous step didn't help you.
EDIT 2: according to your comments, the echo %PATH% line I asked you to add gave the following output:
E:\jdk1.6\bin;E:\apache-ant-1.7.0\bin;E:\jboss-6.0\bin\run.bat
Clearly this doesn't contain C:\WINDOWS\system32, so JBoss definitely won't be able to find findstr. But I don't understand why the PATH is ending up like this. How are you starting JBoss - as a service or by running run.bat? Is JBoss being run under some user account which has been set up with a very restricted PATH? Do you have some other script which is manipulating the PATH before JBoss starts? Also, which version of Windows are you using?
Also, it's not immediately clear to me from your three comments
I'm already checked that the findstr application is already in that path C:\WINDOWS\system32\
E:\jboss-6.0\bin\run.bat
Am also set that in the system variables in Environmental Variables
whether C:\WINDOWS\system32 is in the PATH in Control Panel > System > Environment Variables. Is C:\WINDOWS\system32 in the PATH in the System Variables section within the Environment Variables dialog?
This doesn't seem to be an issue with JBoss. This seems to be more of an issue with the environment within which you are running it. I can quite imagine a lot of other programs would be unhappy with being run in a similar environment.