Home » Questions » Computers [ Ask a new question ]

After-the-fact remote nohup with tcsh

After-the-fact remote nohup with tcsh

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

Asked by: Guest | Views: 232
Total answers/comments: 1
Guest [Entry]

"This post may help. The recommendation is:

background the process (with Ctrl-Z, then bg)
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..."