I have a tcsh instance in an xterm that is running a long-term (weeks?) process. The Xvnc server it's running under went out in the weeds; it's consuming 100% CPU and is unresponsive. (This is a known bug and I know that it's unrecoverable.)

The long-term process is currently blocking on stdout.

Is there any way I can kill an underlying process — the tcsh, the xterm, whatever — and keep that long-term process running?

(Please, no answers about screen. I know. It's not my process; it's a user's. They won't learn.)

2 Answers 2


This post may help. The recommendation is:

  1. background the process (with Ctrl-Z, then bg)
  2. run disown -h %[jobid] (likely a bash-ism, so you'll have to translate for tcsh)

The bad news, of course, is that the bg would need to be done in the same shell the process is running in... but ... it might already be backgrounded.

The really bad news is that the disown call might need to be done in the same shell. In which case, yes, you're screwed. But I'm not sure, maybe root can force-disconnect it.

Hmm. Possible good news -- tcsh does the disown automatically:

If tcsh exits abnormally, it disowns jobs running in the background automatically when it exits.

So, if your long-term process is already backgrounded, killing its tcsh parent should allow it to continue. The process is now disconnected from the starting terminal. (If not, see "bad news" above.)

Unfortunately, it's not screen, so there's no real reconnecting. You can fake it with gdb maybe (again, from the first link):

[...] with some dirty hacks, it is not impossible to reopen a process' stdout/stderr/stdin.

So you could still create a blank screen window (for instance that runs sleep).

And then use gdb for instance to attach to the process, do some call close(0)
call close(1)
call close(2)
call open("/dev/pts/xx", ...)
call dup(0)
call dup(0)

The process' output would go to screen. It wouldn't be attached to that screen terminal, so for instance[sic] would kill the "sleep" command, not the process, but that could be enough for the OP.

I wonder if there shouldn't be "call dup(1)" and "call dup(2)" in that process as well...

  • Yeah, it's a foreground process, so I guess I'm screwed.
    – wfaulk
    Oct 2, 2009 at 16:44
  • Yeah. but like you said, it's not your process, not your fault. sorry you get stuck with the mess, tho. Oct 2, 2009 at 18:56
  • 2
    This totally just saved my ass. I encountered the same problem I posted about initially, which was that the process was blocking on STDOUT when the X server (and, I guess, the xterm in between) wedged. It turns out I didn't really need to do anything except close STDOUT. That output was irrelevant; the real data is in a log file somewhere. So I was able to attach with gdb, run "call close(1)" and then "cont" and it's moving along again. Thanks so much!
    – wfaulk
    Oct 12, 2009 at 16:12
  • huh! interesting. that unfroze everything? weirdness. glad it helped tho! Oct 12, 2009 at 23:18
  • 2
    It might be worth pointing out that sending "Ctrl-Z" to a foreground process and sending SIGSTOP to its pid are the same thing. (SIGCONT starts the process back again.) I don't know if this would be helpful for others in the same situation or not, but, in my quick testing, sending SIGSTOP followed by SIGCONT duplicates "Ctrl-Z" followed by bg.
    – wfaulk
    Nov 3, 2014 at 17:03

These questions refer to a program called Cryopid which may help you. I don't have any experience with it, however.

Moving a process between hosts

Moving xterms between X sessions

Nohup and screen a process

  • CryoPID sounds really neat, but I had a family of processes, and it doesn't support freezing and resuming multiple processes, at least not yet.
    – wfaulk
    Oct 12, 2009 at 16:13

You must log in to answer this question.

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