6

I have a job that runs in the background via ctrl + z and bg, and after reconnecting ssh I cannot find that job in the jobs command but can find it in ps grep. For now, I searched this and I get the tmux may be a better solution, however， I am still wondering why exit ssh will lose jobs in the jobs command. I've put that in the background, it should exist after reconnecting, Am I right?

How can I manage jobs after I disconnect from my tty/ssh session?

Yang Xu
  • 93
  • 5
  • 2
    If you ever have these kinds of needs in the future, be sure to utilize tmux or screen instead of scratching your head against Ctrl-Z and bg. – iBug Sep 30 '22 at 11:01

1 Answers1

14

Shell jobs don't belong directly to the user. I mean there is no global list of jobs for the user. A job can be a process that belongs to the user and you can find all processes belonging to the user. But each job as a job belongs to some shell process, the shell keeps a list and tracks its jobs. If the shell process terminates, the job process may survive; but it's only "historically" a job, because now there is no list of jobs that contains this process.

When you disconnect, the shell process terminates. When you connect again, a new shell process is created for you. The new process knows nothing about jobs of any other shell process (still running or terminated). There is no mechanism that allows the new shell to adopt jobs of another shell.

Shells inside tmux or screen can survive your disconnection. When you connect again, you regain access to exactly the same shells. Each will remember its own jobs, as if nothing happened, because from their point of view nothing has happened.

Kamil Maciorowski
  • 21,864
  • 1
    So, Is there a way to rebind the process to the jobs of reconnected SSH? I can find these processes by ps grep. – Yang Xu Sep 30 '22 at 04:19
  • 2
    @YangXu There is reptyr, but it won't make the process a job in the new shell. – Kamil Maciorowski Sep 30 '22 at 05:36
  • The mechanism for why these jobs are likely killed, is that when the connection ends, a SIGHUP (hangup) signal to all processes that contain the session id of the controlling tty. processes can ignore this signal but do not by default do this. Since you want to regain control you will need to use tmux or screen. If you just wanted them to live forever, even if not connected to any shell you can use nohup cmd... – toppk Sep 30 '22 at 11:40
  • You could also mention nohup, which allows processes to continue running after you disconnect, although you can't manage them when reconnecting. – Barmar Sep 30 '22 at 14:29
  • 2
    @Barmar The question states "I can find it in ps grep", so it's about a process that survives anyway. – Kamil Maciorowski Sep 30 '22 at 14:54
  • I feel this answer could benefit from including the concept of sessions. As in, jobs are limited to a session. A new login is a new session that does not see or inherit jobs from other (previous or current) sessions. – marcelm Sep 30 '22 at 19:13
  • @marcelm sleep 60 & jobs; sh -mc 'sleep 30& ps -o sess,command; jobs' – This shows me two different lists of jobs in two different shells in the same session. It would be like this also for two different shells in two different sessions. It would be the same today and tomorrow. What difference does the session make then? For now it seems to me the same or different session is as relevant to the issue as the same or different date. If I tried to include the concept of sessions in my answer, I could only derive as much sense from it as from including the concept of dates. What am I missing? – Kamil Maciorowski Oct 01 '22 at 02:53