I'm trying to start a test server via ssh but it always dies once i disconnect from ssh.
Is there a way to start a process (run the server) so it doesn't die upon the end of my ssh session?
I'm trying to start a test server via ssh but it always dies once i disconnect from ssh.
Is there a way to start a process (run the server) so it doesn't die upon the end of my ssh session?
As an alternative to nohup
, you could run your remote application inside a terminal multiplexor, such as GNU screen
or tmux
.
Using these tools makes it easy to reconnect to a session from another host, which means that you can kick a long build or download off before you leave work and check on its status when you get home. For instance. I find this particularly useful when doing development work on servers that are very remote (in a different country) with unreliable connectivity between me and them, if the connection drops, I can simply reconnect and carry on without losing any state.
Yes; you can use the nohup
command to swallow the HUP ("hangup") signal that is sent to your program when you hang up your SSH session.
Alternatively, if you're writing the server yourself, you can code it to register a handler for the HUP signal, and swallow it inside the program (rather than using an external nohup
program that does the same).
In addition to the other replies, you could start your test server thru batch (or at
) but as Brian answered you should call daemon
And you could pass the -f
option to ssh
As an alternative to nohup
, screen
, et al. you could revise your server to invoke daemon
to detach it from the terminal. This is the idiomatic way to write services for linux.
See also daemon(3)
.
If you're SSHing to a Linux distro that has systemd, you can use systemd-run
to launch a process in the background (in systemd's terms, "a transient service"). For example, assuming you want to ping something in the background:
systemd-run --unit=pinger ping 10.8.178.3
The benefit you'll get with systemd over just running a process with nohup
is that systemd will track the process and it's children, keep logs, remember the exit code and allow you to cleanly kill the process and all it's children. Examples:
See the status and the last lines of output:
systemctl status pinger
Stream the output:
journalctl -xfu pinger
Kill:
systemctl kill pinger