How to Start a Process That Won't End When My Ssh Session Ends

How to prevent a background process from being stopped after closing SSH client in Linux

Check out the "nohup" program.

How to maintain command after exiting SSH?

Found out the issue was with cPanel, as it did not support node.js. I moved to DigitalOcean and it worked fantastically there.

How do I kill a backgrounded/detached ssh session?

well i dont want to add an & at the end of the commands as the connection will die if the console wintow is closed ... so i ended up with an ps-grep-awk-sed-combo

ssh -f -N -L localhost:12345:otherHost:12345   otherUser@otherHost
echo `ps aux | grep -F 'ssh -f -N -L localhost' | grep -v -F 'grep' | awk '{ print $2 }'` > /tmp/synergyPIDs/ssh
synergyc localhost
echo `ps aux | grep -F 'synergyc localhost' | grep -v -F 'grep' | awk '{ print $2 }'` > /tmp/synergyPIDs/synergy

(you could integrate grep into awk, but im too lazy now)

How to make a program continue to run after log out from ssh?

Assuming that you have a program running in the foreground, press ctrl-Z, then:

[1]+  Stopped                 myprogram
$ disown -h %1
$ bg 1
[1]+ myprogram &
$ logout

If there is only one job, then you don't need to specify the job number. Just use disown -h and bg.

Explanation of the above steps:

You press ctrl-Z. The system suspends the running program, displays a job number and a "Stopped" message and returns you to a bash prompt.

You type the disown -h %1 command (here, I've used a 1, but you'd use the job number that was displayed in the Stopped message) which marks the job so it ignores the SIGHUP signal (it will not be stopped by logging out).

Next, type the bg command using the same job number; this resumes the running of the program in the background and a message is displayed confirming that.

You can now log out and it will continue running..

how to send ssh job to background

Can you stop the process right now? If so, launch screen, start the process and detach screen using ctrl-a then ctrl-d. Use screen -r to retrieve the session later.

This should be available in most distros, failing that, a package will definitely be available for you.

Command 'exit' doesn't work when some background process is still piping out

Short answer: You should redirect the standard input, output, and error for the pm2 process:

pm2 log < /dev/null > /dev/null 2>&1 &

This will prevent the remote ssh server from holding the session open until pm2 exits.

Longer answer:

ssh user@mysever <<'HEREDOC'
...
pm2 log &

When you run ssh in this fashion, the remote ssh server will launch a copy of the remote user's shell to handle the session. To relay input and output from the remote session, the remote ssh server will allocate either a TTY or a set of pipes. Then it sets the TTY or pipes as the standard input, output, and error for the shell process.

So, on the remote system, you have either a TTY or a set of pipes connecting the remote shell process to the SSH server process. Any commands invoked by the shell will inherit the TTY or set of pipes as the command's standard input etc. (unless you use shell features to redirect the standard file handles).

You might think that the ssh server will terminate the session when the remote shell process exits. But that's not what happens. The ssh server terminates the session when it reads an end-of-file condition on the TTY or the pipe connected to the standard output for the session.

In your case, you're invoking this pm2 command on the remote system, and it's inheriting the remote session's standard output. As long as this program is running, the remote ssh server won't get an EOF on the standard output pipe and it won't terminate the session.

The fix is to redirect input for the pm2 process so it doesn't inherit the standard handles that are connected to the ssh server:

pm2 log < /dev/null > /dev/null 2>&1 &

You could redirect to a file instead of /dev/null if you want to capture the output. I think only the standard output redirection is strictly necessary, but you should redirect standard input and error as well just to be sure.



Related Topics



Leave a reply



Submit