Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.)

share|improve this question
add comment

2 Answers

up vote 8 down vote accepted

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)
detach

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...

share|improve this answer
    
Yeah, it's a foreground process, so I guess I'm screwed. –  wfaulk Oct 2 '09 at 16:44
    
Yeah. but like you said, it's not your process, not your fault. sorry you get stuck with the mess, tho. –  quack quixote Oct 2 '09 at 18:56
1  
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 '09 at 16:12
    
huh! interesting. that unfroze everything? weirdness. glad it helped tho! –  quack quixote Oct 12 '09 at 23:18
    
No, it should be dup(0). The dup(0) calls take fd 0 and copy it over the next free descriptors, which happen to be 1 and 2, if you've closed them previously. dup2(fd1, fd2) might be a more clear spelling, assuming you can remember which is the source and which is the destination (I never can remember that). –  Marius Gedminas Sep 18 '10 at 15:41
add comment

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

share|improve this answer
    
Thanks. Good pointers. –  wfaulk Oct 4 '09 at 21:26
    
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 '09 at 16:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.