I have a Spring MVC application that runs with the normal SpringApplication.run(Application.class, args); statement. When I run it and then close the terminal window, it kills the process. How can I prevent it from shutting down when I close the terminal window?
I'm using OSX 10.9, Mavericks.
Thank you very much.
As Dave Syer says, you're best to use the nohup command which will prevent the child process from hanging up when the terminal window closes.
For example:
nohup java -jar name.jar 2>&1 >output.log &
That will send both the standard out and standard error to the output.log file. You can omit the >output.log and nohup will use the default log file called nohup.out.
Related
I have a command that I would like to create a service from. For example: "java -jar agent.jar" (the command is blocking - when closing the cmd it will stop the agent). I would like to make the command run as a service in the background so I can log out from my user and it will still work.
On Linux, I know for a fact that I can use nohup mycommand. The problem is on Windows OS. Also, replace java with javaw will solve the blocking issue but when I sign out it will still kill the agent.
How do I do that?
I'll appreciate your help!
Tomer.
Use Windows services feature.
Read this answer.
And this solution.
Spring has this documentation for running an executable spring boot jar.
However, I ran this jar from terminal using the nohup linux command, and worked fine.
The question is: Using nohup or using init.d service, will have the same result for the application? Or using the init.d is the correct way always?
They do different things. nohup runs a command, and ignores the HANGUP (HUP) signal. init.d is for running a command automatically at server start-up (and shutting commands down orderly on shutdown). If you want your spring boot application to run automatically after the system restarts, put it in init.d - if you want to manually start it after every reboot you can use nohup.
nohup runs the command in a way that will be immune to hangups, which could cause problems. A lot of programs are designed to re-read their configuration files, restart, or do other things when they receive HUP signals (most services/daemons restart or re-read configs). Unless you specifically want to ignore HUP signals, using nohup isn't the best solution.
You can use & after the command in order to run it in the background, and if you want to avoid output to the terminal, you can send the output to /dev/null:
mycommand > /dev/null 2>&1 &
The 2>&1 will send stderr to stdout, so it goes to /dev/null.
I have a java program acting as a Network server. Thanks the the utility update-rc.d I have installed a service on a Debian / Unix server in order to have it running all the time without being connected during a SSH session.
Because my program is in java bytecode, and not a native unix executable, I have used the following tutorial to make it work as a daemon: java as a daemon service
The problem is that I don't see the output of the program any more. I need to see the output of the program, as it shows a stack trace when an exception happens. How to redirect standard and error output streams to a log file ?
Alternative question: How to run the java program and have it continusly running even when I log out from SSH ?
You can wrap the app launch command into a shell script and redirect output there:
/usr/bin/java -jar app.jar >> /var/log/app/app.log 2>&1
But I'd recommend to use some logging framework to gain more control over log files. Something like slf4j with logback or any other backend.
Alternative question: How to run the java program and have it continusly running even when I log out from SSH ?
You can do this with screen:
screen java -jar app.jar ...
Then after SSH login run
screen -r
to resume screen session.
I've developed a Java console application that when start, open a console window and remain in foreground, i want to start that application in background .
Now i launch the application by this command line :
java -jar myapp.jar
Is there a way to achieve this behaviour ?
It's enough change the command line parameter or i need to do some change on my code ?
The answer is operating system dependent.
*nix: <your command> &
Windows: (opens a new console): start <your command>
Windows: (doesn't open a new console): start /b <your command>
If you are doing this in anything unix based then you can append & to the end which will spawn a new thread and keept it running in the background.
java -jar myapp.jar &
If you really just want it to run in the background, java -jar myapp.jar & will do the job. That way, it'll still die when the shell closes, but you can keep using your shell.
If you really want it run as a daemon, nohup java -jar myapp.jar & will do the job. That way, it'll continue to live when the shell closes.
If you want this to be reliable, you can prepare an init script or upstart job definition, or run it via Vixie cron(8) #reboot specifier to make it start at boot.
Given that you're using Windows, you might consider Java Service Wrapper. I have used it on a project in the past.
We have a jboss application server running a webapp. We need to implement a "restart" button somewhere in the UI that causes the entire application server to restart. Our naive implementation was to call our /etc/init.d script with the restart command. This shuts down our application server then restarts it.
However, it appears that when the java process shuts down, the child process running the restart scripts dies as well, before getting to the point in the script where it starts the app server again.
We tried variations on adding '&' to the places where scripts are called, but that didn't help. Is there some where to fire the script and die without killing the script process?
Try using the nohup command to run something from within the script that you execute via Java. That is, if the script that you execute from Java currently runs this:
/etc/init.d/myservice restart
then change it to do this:
nohup /etc/init.d/myservice restart
Also, ensure that you DO NOT have stdin, stdout, or stderr being intercepted by the Java process. This could cause problems, potentially. Thus, maybe try this (assuming bash or sh):
nohup /etc/init.d/myservice restart >/dev/null 2>&1
Set your signal handlers in the restart script to ignore your signal with trap:
trap "" 2 # ignore SIGINT
trap "" 15 # ignore SIGTERM
After doing this, you'll need to kill your restart script with some other signal when needed, probably SIGKILL.