How can I do to quit the SSH session and leave some current command line running normally? [duplicate]
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
This question already has an answer here:
How can I keep processes running on a remote server even after turning off the terminal machine?
2 answers
I have a running command that should take about 10 days.
As the process is search files in all subdirectories and converting videos.
To each video comand line found, the system changes the process number.
This is the line I'm running:
find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ;
How can I do to quit the SSH session and leave some current command line running normally?
I'm already on day 2 and my fear is that my connection will be interrupted simply and I lose all this time.
ssh command-line
asked Jan 13 at 15:15
Max
1043
marked as duplicate by Thomas Dickey, Rui F Ribeiro, Raphael Ahrens, jimmij, Anthony Geoghegan Jan 14 at 18:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |Â
up vote
0
down vote
favorite
This question already has an answer here:
How can I keep processes running on a remote server even after turning off the terminal machine?
2 answers
I have a running command that should take about 10 days.
As the process is search files in all subdirectories and converting videos.
To each video comand line found, the system changes the process number.
This is the line I'm running:
find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ;
How can I do to quit the SSH session and leave some current command line running normally?
I'm already on day 2 and my fear is that my connection will be interrupted simply and I lose all this time.
ssh command-line
asked Jan 13 at 15:15
Max
1043
marked as duplicate by Thomas Dickey, Rui F Ribeiro, Raphael Ahrens, jimmij, Anthony Geoghegan Jan 14 at 18:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
You should probably have started the session withnohup?
– Weijun Zhou
Jan 13 at 15:25
1
i normally run commands in background with&at the end of command thendisown
– user137124
Jan 13 at 15:57
2
@ThomasDickey This is obviously not a duplicate as this question is about saving a running process and not about preparations to avoid the problem.
– Hauke Laging
Jan 13 at 17:43
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This question already has an answer here:
How can I keep processes running on a remote server even after turning off the terminal machine?
2 answers
I have a running command that should take about 10 days.
As the process is search files in all subdirectories and converting videos.
To each video comand line found, the system changes the process number.
This is the line I'm running:
find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ;
How can I do to quit the SSH session and leave some current command line running normally?
I'm already on day 2 and my fear is that my connection will be interrupted simply and I lose all this time.
ssh command-line
asked Jan 13 at 15:15
Max
1043
This question already has an answer here:
How can I keep processes running on a remote server even after turning off the terminal machine?
2 answers
I have a running command that should take about 10 days.
As the process is search files in all subdirectories and converting videos.
To each video comand line found, the system changes the process number.
This is the line I'm running:
find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ;
How can I do to quit the SSH session and leave some current command line running normally?
I'm already on day 2 and my fear is that my connection will be interrupted simply and I lose all this time.
This question already has an answer here:
How can I keep processes running on a remote server even after turning off the terminal machine?
2 answers
ssh command-line
asked Jan 13 at 15:15
Max
1043
asked Jan 13 at 15:15
Max
1043
asked Jan 13 at 15:15
Max
1043
asked Jan 13 at 15:15
Max
1043
1043
marked as duplicate by Thomas Dickey, Rui F Ribeiro, Raphael Ahrens, jimmij, Anthony Geoghegan Jan 14 at 18:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Thomas Dickey, Rui F Ribeiro, Raphael Ahrens, jimmij, Anthony Geoghegan Jan 14 at 18:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
You should probably have started the session withnohup?
– Weijun Zhou
Jan 13 at 15:25
1
i normally run commands in background with&at the end of command thendisown
– user137124
Jan 13 at 15:57
2
@ThomasDickey This is obviously not a duplicate as this question is about saving a running process and not about preparations to avoid the problem.
– Hauke Laging
Jan 13 at 17:43
add a comment |Â
You should probably have started the session withnohup?
– Weijun Zhou
Jan 13 at 15:25
1
i normally run commands in background with&at the end of command thendisown
– user137124
Jan 13 at 15:57
2
@ThomasDickey This is obviously not a duplicate as this question is about saving a running process and not about preparations to avoid the problem.
– Hauke Laging
Jan 13 at 17:43
You should probably have started the session with
nohup?– Weijun Zhou
Jan 13 at 15:25
You should probably have started the session with
nohup?– Weijun Zhou
Jan 13 at 15:25
1
1
i normally run commands in background with
& at the end of command then disown– user137124
Jan 13 at 15:57
i normally run commands in background with
& at the end of command then disown– user137124
Jan 13 at 15:57
2
2
@ThomasDickey This is obviously not a duplicate as this question is about saving a running process and not about preparations to avoid the problem.
– Hauke Laging
Jan 13 at 17:43
@ThomasDickey This is obviously not a duplicate as this question is about saving a running process and not about preparations to avoid the problem.
– Hauke Laging
Jan 13 at 17:43
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
With
netstat --inet --inet6 -lnp | grep :22
you can find the PID of the sshd process. And with
# pstree -p -n 1527
sshd(1527)─┬─sshd(32296)───bash(32298)───screen(32336)
└─sshd(32723)───bash(32725)───find(32763)───sleep(323)
you can see the subprocesses.
If bash(32725) dies then it kills find(32763) with SIGHUP. This could be prevented by making find run in the background and using the shell builtin disown. But if sshd(32723) dies then the controlling terminal for all its child processes and their children goes away and thus the kernel kills them.
You can suspend shd(32723) and bash(32725). That way they cannot kill the find when e.g. the SSH connection is broken:
kill -stop 32723 32725
And next time be a bit cleverer in advance. There is hardly any reason not to use screen or tmux when you login over a network.
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
@Max With a non-respondingsshdyou do not log out at all. On the client side you can either kill thesshprocess, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>
– Hauke Laging
Jan 13 at 17:40
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
@Max I think you are on the safe side withkill -stop. But then you cannot "see" the process any more. This can work only if neitherfindnor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then usekill. If you are not then stop the process and usescreen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?
– Hauke Laging
Jan 13 at 20:18
1
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system withKillUserProcessesturned on!
– Fox
Jan 14 at 18:06
 |Â
show 1 more comment
up vote
-2
down vote
nohup find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ; &
You will get a warning on the first quit, but if you repeat the quit the program should keep running - unless it needs terminal input.
But I was too fast, overlooked the fact that your program is already running.
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
Well I could have posted this as an answer but I didn't because it seems that the command is already running withoutnohup...
– Weijun Zhou
Jan 13 at 16:09
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
With
netstat --inet --inet6 -lnp | grep :22
you can find the PID of the sshd process. And with
# pstree -p -n 1527
sshd(1527)─┬─sshd(32296)───bash(32298)───screen(32336)
└─sshd(32723)───bash(32725)───find(32763)───sleep(323)
you can see the subprocesses.
If bash(32725) dies then it kills find(32763) with SIGHUP. This could be prevented by making find run in the background and using the shell builtin disown. But if sshd(32723) dies then the controlling terminal for all its child processes and their children goes away and thus the kernel kills them.
You can suspend shd(32723) and bash(32725). That way they cannot kill the find when e.g. the SSH connection is broken:
kill -stop 32723 32725
And next time be a bit cleverer in advance. There is hardly any reason not to use screen or tmux when you login over a network.
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
@Max With a non-respondingsshdyou do not log out at all. On the client side you can either kill thesshprocess, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>
– Hauke Laging
Jan 13 at 17:40
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
@Max I think you are on the safe side withkill -stop. But then you cannot "see" the process any more. This can work only if neitherfindnor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then usekill. If you are not then stop the process and usescreen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?
– Hauke Laging
Jan 13 at 20:18
1
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system withKillUserProcessesturned on!
– Fox
Jan 14 at 18:06
 |Â
show 1 more comment
up vote
2
down vote
With
netstat --inet --inet6 -lnp | grep :22
you can find the PID of the sshd process. And with
# pstree -p -n 1527
sshd(1527)─┬─sshd(32296)───bash(32298)───screen(32336)
└─sshd(32723)───bash(32725)───find(32763)───sleep(323)
you can see the subprocesses.
If bash(32725) dies then it kills find(32763) with SIGHUP. This could be prevented by making find run in the background and using the shell builtin disown. But if sshd(32723) dies then the controlling terminal for all its child processes and their children goes away and thus the kernel kills them.
You can suspend shd(32723) and bash(32725). That way they cannot kill the find when e.g. the SSH connection is broken:
kill -stop 32723 32725
And next time be a bit cleverer in advance. There is hardly any reason not to use screen or tmux when you login over a network.
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
@Max With a non-respondingsshdyou do not log out at all. On the client side you can either kill thesshprocess, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>
– Hauke Laging
Jan 13 at 17:40
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
@Max I think you are on the safe side withkill -stop. But then you cannot "see" the process any more. This can work only if neitherfindnor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then usekill. If you are not then stop the process and usescreen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?
– Hauke Laging
Jan 13 at 20:18
1
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system withKillUserProcessesturned on!
– Fox
Jan 14 at 18:06
 |Â
show 1 more comment
up vote
2
down vote
up vote
2
down vote
With
netstat --inet --inet6 -lnp | grep :22
you can find the PID of the sshd process. And with
# pstree -p -n 1527
sshd(1527)─┬─sshd(32296)───bash(32298)───screen(32336)
└─sshd(32723)───bash(32725)───find(32763)───sleep(323)
you can see the subprocesses.
If bash(32725) dies then it kills find(32763) with SIGHUP. This could be prevented by making find run in the background and using the shell builtin disown. But if sshd(32723) dies then the controlling terminal for all its child processes and their children goes away and thus the kernel kills them.
You can suspend shd(32723) and bash(32725). That way they cannot kill the find when e.g. the SSH connection is broken:
kill -stop 32723 32725
And next time be a bit cleverer in advance. There is hardly any reason not to use screen or tmux when you login over a network.
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
With
netstat --inet --inet6 -lnp | grep :22
you can find the PID of the sshd process. And with
# pstree -p -n 1527
sshd(1527)─┬─sshd(32296)───bash(32298)───screen(32336)
└─sshd(32723)───bash(32725)───find(32763)───sleep(323)
you can see the subprocesses.
If bash(32725) dies then it kills find(32763) with SIGHUP. This could be prevented by making find run in the background and using the shell builtin disown. But if sshd(32723) dies then the controlling terminal for all its child processes and their children goes away and thus the kernel kills them.
You can suspend shd(32723) and bash(32725). That way they cannot kill the find when e.g. the SSH connection is broken:
kill -stop 32723 32725
And next time be a bit cleverer in advance. There is hardly any reason not to use screen or tmux when you login over a network.
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
answered Jan 13 at 16:39
Hauke Laging
53.4k1282130
53.4k1282130
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
@Max With a non-respondingsshdyou do not log out at all. On the client side you can either kill thesshprocess, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>
– Hauke Laging
Jan 13 at 17:40
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
@Max I think you are on the safe side withkill -stop. But then you cannot "see" the process any more. This can work only if neitherfindnor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then usekill. If you are not then stop the process and usescreen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?
– Hauke Laging
Jan 13 at 20:18
1
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system withKillUserProcessesturned on!
– Fox
Jan 14 at 18:06
 |Â
show 1 more comment
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
@Max With a non-respondingsshdyou do not log out at all. On the client side you can either kill thesshprocess, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>
– Hauke Laging
Jan 13 at 17:40
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
@Max I think you are on the safe side withkill -stop. But then you cannot "see" the process any more. This can work only if neitherfindnor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then usekill. If you are not then stop the process and usescreen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?
– Hauke Laging
Jan 13 at 20:18
1
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system withKillUserProcessesturned on!
– Fox
Jan 14 at 18:06
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
Okay, I think I got it. I can suspend shd(32723) and bash(32725) process. How do I return to this task run and log out safely?
– Max
Jan 13 at 17:33
@Max With a non-responding
sshd you do not log out at all. On the client side you can either kill the ssh process, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>– Hauke Laging
Jan 13 at 17:40
@Max With a non-responding
sshd you do not log out at all. On the client side you can either kill the ssh process, wait for it to die on its own due to the non-responding server or have it break the session and exit by pressing <enter>, <~>, and <.>– Hauke Laging
Jan 13 at 17:40
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
Do you believe that the best then would be to start the whole process again? I'd rather do it now and lose only 2 days than on day 9 something happen and I have to repeat it all over again. Can you help me? What would my command line look like so I can get out of here and then return and continue seeing the whole process running?
– Max
Jan 13 at 20:12
@Max I think you are on the safe side with
kill -stop. But then you cannot "see" the process any more. This can work only if neither find nor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then use kill. If you are not then stop the process and use screen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?– Hauke Laging
Jan 13 at 20:18
@Max I think you are on the safe side with
kill -stop. But then you cannot "see" the process any more. This can work only if neither find nor any of the subprocesses try to read from or write to the terminal. So if you are sure there will be neither reads nor writes then use kill. If you are not then stop the process and use screen. Do you lose time at all when stopping? You can skip the files you already processed, can't you? Is it difficult to detect them?– Hauke Laging
Jan 13 at 20:18
1
1
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system with
KillUserProcesses turned on!– Fox
Jan 14 at 18:06
+1 for (paraphrased) always use screen. Just make sure you're not on a systemd system with
KillUserProcesses turned on!– Fox
Jan 14 at 18:06
 |Â
show 1 more comment
up vote
-2
down vote
nohup find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ; &
You will get a warning on the first quit, but if you repeat the quit the program should keep running - unless it needs terminal input.
But I was too fast, overlooked the fact that your program is already running.
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
Well I could have posted this as an answer but I didn't because it seems that the command is already running withoutnohup...
– Weijun Zhou
Jan 13 at 16:09
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
add a comment |Â
up vote
-2
down vote
nohup find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ; &
You will get a warning on the first quit, but if you repeat the quit the program should keep running - unless it needs terminal input.
But I was too fast, overlooked the fact that your program is already running.
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
Well I could have posted this as an answer but I didn't because it seems that the command is already running withoutnohup...
– Weijun Zhou
Jan 13 at 16:09
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
add a comment |Â
up vote
-2
down vote
up vote
-2
down vote
nohup find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ; &
You will get a warning on the first quit, but if you repeat the quit the program should keep running - unless it needs terminal input.
But I was too fast, overlooked the fact that your program is already running.
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
nohup find . -exec ffmpeg -i -vf scale=1280:720 -vcodec libx264 -crf 30 -b:v 300000 _250.mp4 ; &
You will get a warning on the first quit, but if you repeat the quit the program should keep running - unless it needs terminal input.
But I was too fast, overlooked the fact that your program is already running.
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
edited Jan 13 at 16:04
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
answered Jan 13 at 15:59
Gerard H. Pille
1,219212
1,219212
Well I could have posted this as an answer but I didn't because it seems that the command is already running withoutnohup...
– Weijun Zhou
Jan 13 at 16:09
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
add a comment |Â
Well I could have posted this as an answer but I didn't because it seems that the command is already running withoutnohup...
– Weijun Zhou
Jan 13 at 16:09
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
Well I could have posted this as an answer but I didn't because it seems that the command is already running without
nohup ...– Weijun Zhou
Jan 13 at 16:09
Well I could have posted this as an answer but I didn't because it seems that the command is already running without
nohup ...– Weijun Zhou
Jan 13 at 16:09
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
He restarted anyhow, in which case he could have used nohup.
– Gerard H. Pille
Jan 13 at 21:55
add a comment |Â
You should probably have started the session with
nohup?– Weijun Zhou
Jan 13 at 15:25
1
i normally run commands in background with
&at the end of command thendisown– user137124
Jan 13 at 15:57
2
@ThomasDickey This is obviously not a duplicate as this question is about saving a running process and not about preparations to avoid the problem.
– Hauke Laging
Jan 13 at 17:43