Make it simple.

I invoked java xxx... on Machine A using putty to connect from Machine B. However I cannot reach Machine B. How can I connect Machine A from Machine C to set the running process java xxx... could not be terminated when Machine B shuts down?


I'm connecting to a server(Machine A) using putty, and I'm running a process on it. However I have to reboot my computer(Machine B), which could terminate the connection as well as putty. Because I didn't set nohup on the process which I'm running, this could be terminated. I cannot use putty to set disown for some reasons. So I want to use Machine C to open putty to connect to the server(Machine A) and set the process I'm running that it won't be terminated when I reboot Machine B.

Is there any way to do this? I know I can use disown if I'm using the same shell process. But now is not this case.


4 Answers 4


You could attach a debugger to it to make the process ignore the SIGHUP signal:

gdb --pid="$pid" --batch -ex 'call signal(1,1)' -ex detach

(where $pid is the id of that process). You can also extend that to redirect its stdout/stdin/stderr..., but then you might as well look at the other questions referenced here about reattaching a process to another terminal (or search for reptyr on this site).

Another option would be to suspend the process that allocated and drives the pseudo terminal that is controlling your java process. That way, it will not die even if the ssh connection is killed and as long as java doesn't not write much to the terminal, it will not be affected.

Here a test with a sleep process:

$ pstree -sp "$(pidof sleep)"
$ kill -s STOP 62826

Now terminate the ssh client, then sleep is still running:

$ ps -fC sleep
root     62842 62826  0 09:50 pts/8    00:00:00 sleep 100

You'll want to resume that sshd once your java process has terminated so it can exit cleanly.

  • Can gdb be applied to java? I thought it only works on c/c++ programs. May 30, 2014 at 1:24
  • Your java interpreter/VM was probably written in C or C++. In any case, it will most likely be some ELF executable linked to the libc from where that signal() function can be called. May 30, 2014 at 7:19
  • this is much too complicated and resource intensive, given the fact that the *ix standard nohup is intended for this purpose.
    – Floyd
    May 30, 2014 at 8:13
  • @Floyd, nohup can't be used after the process has already started. What you want here is to make an already running program ignore the HUP signals. May 30, 2014 at 8:25
  • @stephane: you are right, I missed the part that he needs to set nohup from another process
    – Floyd
    May 30, 2014 at 18:54

I wanted to give a chance to the kill command with some specific signal but have not found and proper signal to do that. I would say you cannot do it with built-in stuff. There are people who have written code however:

How can I disown a running process and associate it to a new screen shell?


In your case, the best way to do it is using tmux or screen

Here is an example how you can use tmux, screen is pretty much the same.

  1. Putty into your server
  2. install tmux using your favorite package manager
  3. start a new tmux session by: tmux
  4. run your application inside tmux window, e.g.: java -jar blah blah
  5. detach your tmux session by pressing CTRL-B D
  6. next time you want to check the java process (same putty window or from another machine putty in): tmux atta

Since your command is allready running, you need to press CTRL-Z which will bring it to a stopped state, the program is not running, but the program's state is saved and can be restored whenever you want.

You can check what job id your program has by running jobs command. Once you have identified it you can execute bg %your_prog_id that will send your program to the background and will keep running even if you close your session, you can now exit and your program will continue running.

  • That doesn't answer the question. The OP doesn't have access to the terminal where that command was started. He could do a kill -s STOP on the pid, but then the process would still receive a SIGHUP (handled upon resume) if "machine B" is shut down. May 30, 2014 at 8:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .