I'm running CentOS 6 and I have a jar file I'd like to execute with java and have it run in the background. I plan on executing this command from a script, and I also would like to specify the path at which the pid file is output. How can I do all this?
You can use Java Service(Commons Daemon) from apache. Instead of implementing main, your class to execute must provide method for the service execution (start, stop, etc.)
Related
I have to kill a Java process gracefully from windows. The requirement is that there is a Java main class XYZ.java which has a shutdown hook added named ABC.java containing some piece of code.I have to run code present in ABC.java when XYZ.java terminates.
In linux, I am able to do so using 'kill' command.
In windows, I used below command but that's not killing my class gracefully:
WMIC PROCESS where "Name='java.exe' AND CommandLine LIKE '%%XYZ%%'" CALL TERMINATE.However, I am able to achieve this windows by running CTRL+C while running java process XYZ from cmd.
Please suggest.
I have a Java application run as a Windows service using procrun (specifically prunsrv). The service is defined as an exe StartMode so a batch file (run-my-app.bat) is run as the StartImage. Why I am not using jvm or java mode is a different story, not related to this issue (I was unable to run spring boot application with procrun, all examples did not work so I resorted to creating a batch file and calling java -jar my.jar). prunsrv.exe is actually renamed according to the application, say myapp.exe. The problem is that if myapp.exe is killed via the task manager, the java process remains! The batch file run-my-app.bat runs the application using the following line:
start "%APP_NAME%" /b "%JAVA_EXE%" -jar myapp.jar --spring.config.location=application.properties --logging.config=log4j2.xml
The batch file completes and the started Java process remains - I know this because if I print a message after the above "start" command I see the message in the log.
Is there any way to stop the java process when the prunsrv.exe (renamed myapp.exe) is killed?
Child processes will only be closed if they were created as Job objects.
IMHO it's not possible to tell prunsrv.exe to start processes as jobs, so the answer to your question is No.
You can of course terminate every single process individually. There are attempts to kill process trees, but be aware that Windows does not maintain parent-child-relationships. That means: If in a chain of 3 processes the middle one dies, the tree is not available any more.
This question already has answers here:
How to Daemonize a Java Program?
(11 answers)
Closed 7 years ago.
I have built a little daemon in Java and I would like to run it as a service under Unix (e.g. Debian 5). I have read that there is a possibility of using a Java wrapper, but isn't there any other option which is easier to implement? Can't I just use a Unix command such as xxx java -jar program.jar?
Well, if you want to run your java program even when you exit out of your shell, the following is the most simple way:
$nohup java -jar program.jar &
You need to create an appropriate script in /etc/init.d and link it to /etc/rcX.d directories. The script should support at least start, stop, and status parameters. During start it should run java command with appropriate arguments, probably via nohup java <arguments> &. Then you should save PID of your newly-started process to file /var/run/yourservice.pid. stop command should read this PID file and kill this service.
The details vary from distribution to distribution, most distributions provide some macros to make whole job easier. It's best to look at examples of other services in /etc/init.d for your distribution.
Additionally:
If your service isn't accessed from other computers from the network, but it opens some port, make it unavailable with firewall.
If your service processes some 'delicate' data, it's good to add another user and invoke an appropriate sudo command in your /etc/init.d file.
You can start it as:
java -jar program.jar
Unix daemons are normally started by init or started by a script in /etc/init.d or /etc/rc.d, and started at specific runlevels - normally by soft links in /etc/rcX.d. (where X is the intended "runlevel" which is normally 3.
I think debian are moving to using "upstart", a init-replacement. It uses config files in /etc/init to define jobs, and they are quite easy to write. Check that out.
Daemons traditionally closes stdin, sdtout and stderr, and does a "double fork" when starting, in order to detach from the session and also to signal that they are ready to handle whatever they should handle. This is not really necessary, as long as the daemon is not started from the terminal.
If you want a simple shell wrapper to start you program; you just need to write a small shell script:
#!/bin/sh
/full/path/to/java -jar /full/path/to/program.jar
... and make it executable (chmod 755 )
This article contains a few useful tricks for running a Java application as a daemon:
http://barelyenough.org/blog/2005/03/java-daemon/
Alternatively, you can have a look at the Apache Commons Daemon project, although this requires native code (Unix and Win32 supported):
http://commons.apache.org/daemon/
You can use a cron job to schedule your program. You can also check out this article for details on how to run scripts on startup. You can write a script that runs your java program and run it on startup as mentioned in the article.
I would like to submit a job in the hpc and the job is running a java application.
I edit the pbs_script files as following:
#/bin/sh
#PBS -q serial
#PBS -l nodes=1:ppn=4
module load java-jdk/1.7.0-17
java myjavapp
I submitted the job
$qsub pbs_script
however the job return a error: could not find or load main class myjava. but I use the same command to run the java program under the command-line. what is the problem?
Problems such as this one are almost always a difference in the environment of where the job executes versus where you're executing it on the command line. To track it down you usually only need to check that everything is available on all of the nodes in the cluster and that the environment is configured such that the shell which runs the job will find what you're looking for.
Usually this is due not finding the class file. In PBS, the submit script starts execution from the user's home directory, not where you submitted the job. It is often useful to include the following line:
cd $PBS_O_WORKDIR
The command changes the directory on the execute node to the directory that the job was submitted from. Therefore, if you are able to run java myjavapp from the directory that you are submitting from (issuing the qsub), then the $PBS_O_WORKDIR line should work.
Your final submit file would look something like:
#/bin/sh
#PBS -q serial
#PBS -l nodes=1:ppn=4
module load java-jdk/1.7.0-17
cd $PBS_O_WORKDIR
java myjavapp
We face the same problem today.
We can run the java scripts on both master and nodes but when we submit the script through PBS, it fails. The error message is as the same as yours.
We fix the problem by giving the java program the classpath.
java -classpath myjava
Then, the qsub submitted java script can run on any node of the server. : )
Bo
I have compiled my JAVA code into a jar file which I have ported to my ubuntu server. I can start it manually the usual way using java -jar myJar.jar but I'd like my program to be active only for 8 hours. How can I go about setting my jar file up as a process which starts at 9AM and also which automatically closes at 5PM?
I would write a simple launcher script that does the following:
Takes two command line options:
--start
Set up the classpath and environment like JAVA_HOME for the jar to run.
Spawn java -jar myJar.jar.
Capture the process ID and store it in the myJar.pid file in a specific location.
--stop
Read the process ID from myJar.pid and send a kill signal.
Then schedule two jobs in cron, one to call this launcher script with --start argument, at 9AM, and the other to call the same script with --stop argument, at 5PM.
I would also have a shutdown hook registered in my application to gracefully exit when the kill signal is issued.