How to start Jetty correctly

Perhaps this is a really stupid question, since no one else seems to have come across this problem. The Jetty documentation says that jar -jar start.jar starts Jetty, and it does. But when I close the SSH console, it obviously dies.

How can I run it CORRECTLY?

+4
source share
4 answers

One way is to use nohup

 nohup java -jar start.jar 

This has the advantage of writing stdout and stderr to a file

Another way would be to use screen

+1
source

Is it to run on a production machine that will actually serve the Jetty-powered application? I assume this is so, since you are asking about his correct .

If so, you need an appropriate process monitoring system like runit , daemontools , monit , upstart , systemd , or a good ol ' SysV init.d (as mentioned by w / gist ). It depends on your preferences, business needs, and often your underlying operating system.

I use and prefer runit . It is built on solid principles (daemontools), and for my preferred distribution (Debian and Ubuntu) it is packaged by the author himself.

Despite the fact that it is recommended in other answers and mentioned in the comments, starting a long process in screen / tmux or through nohup is not optimal. You have no real control over the process. He will not be restarted if he dies. You must manually find your PID and otherwise manually manage the service. You need to do more manual work in order to get the log output (redirection, sending to an arbitrary file, etc.). You cannot depend reliably on other processes or on other processes. Decent process control systems provide all of these features by default.

If your goal is something completely different, then please update the question to clarify your use case.

+13
source
 java -jar start.jar & 

(to run in the background) should also work, although the recording will not be converted as well as w / nohup.

This is due to the fact that destroying the shell that started the process (for example, by exiting the system) will lead to the destruction of the process if they are not background processes. The screen has been working since then, as it is running in the background, and the screen effectively holds the session while connecting / disconnecting.

+3
source

If you use a * nix system, a better solution would be to use a script in /etc/init.d (or whatever your system equivalent). There is one at https://gist.github.com/404672 .

Otherwise, using nohup or screen from the command line, at least the process will not die when you exit the system. Thus, the process will run in the background using & .

+1
source

Source: https://habr.com/ru/post/1316373/


All Articles