Background process

[TacKat]

I've got a process running the background, ala '&', started at the commandline before I fired up X.

I want to be able to start an xterm and switch into that process. Basically what I want is a way to bring the process out of background execution and give it full control of the system again. Is there a way to do it (besides killing it and starting it again)?

[sans-hubris]

Look up the fg command (sorry, I don't remember off the top of my head as to how it works.)

[TacKat]

Thanks for that, but it doesn't quite accomplish what I need. That works great if I'm still in the terminal, or on the command line, that I started the process from, but I need to be able to bring it to the foreground in a different terminal (which of course has no notion of the jobs that have been started elsewhere).

Am I out of luck?

Edit: Okay, I notice that in top, I can see the tty of each process. If there's a command to change tty (which I guess is the instance of the terminal) I think I can see the jobs it started. Is there a way to do that?

[ 12 August 2001: Message edited by: TacKat ]

[Malakin]

This is a great question, I don't know the answer but I'll try to figure it out later if nobody comes up with an answer. One thing I've found with Linux is - nothing is impossible :)

[TacKat]

No one's got ideas? Looks like I found my next programming project.

[StanLin]

I think you run jobs, get the job number and fg job number. If my memory serves me.

[TacKat]

Yes, that works for some cases, but not what I need. Say I opened an xterm and started a process running in the background. Then I close that xterm, but the background process I started is divorced from the xterm so it continues running. If I open up a new xterm, it spawns a new instance of the shell because I shut down the previous instance. This new instance has no idea of what jobs are currently running (ie, jobs -l returns nothing) so I can't bring a job to the foreground. I need to be able to bring a single process up to the foreground, or at least reattach STDIN and STDOUT to it.

[Linuxcool]

If you start a process by using the ' & ' and then close the xterm, the process is also terminated. That's what happened to me. You have to use the command nohup program_name &. As for getting the program to show up in another terminal, I never tried to do that.

[TacKat]

Yes, typically it would be. In my first instance, I started the program on the CLI and then switched into X, wanting to see the program on an xterm. I couldn't get that to work properly, and as of yet I'm not sure that's possible.

What I have right now is a copy of genome@home running from the nohup. It's parent process is init, and it has no controlling terminal. The shell it was spawned from has been shutdown so there is no record of the job. In effect, it is a runaway process. I would like to be able to bring that back under control (ie, hook the output and input to a terminal) so that I can monitor progress and close it if need be, without using a "kill" on it.

So is there anyway, other than "kill", to bring a completely divorced process back under user control?

[Malakin]

You can use screen to do this.

If you're not familiar with screen I'll give a quick description of how to use it.

Say your command line program is called "myprogram"

Open up a terminal and type "screen myprogram" then type "Ctrl-a" then "d" and it will detach that program. You can see the list of detached programs by typing "screen -list", now you can type "screen -r" from *any* terminal and you will be back in control of the program. "screen -r PID" to select which detached window if there are more then one.

If you want to use this for startup scripts you can use "screen -m -d myprogram" and it will run it detached. use -D if you want the screen session to auto end itself when the script ends.

"man screen" has tons of info on screen.

[TacKat]

Excellent. Still no way to get control of a runaway process, but this will work for what I need. Thanks a ton.

[Strike]

if you want to be really sneaky (and 1337), this might work (don't really wanna try it right now though I'm really interested in what results you get) ... it deals with the /proc filesystem and modifying it, so you have to be root.

Basically, every process has a little entry in /proc under /proc/<PID-of-process> . For example, my shell has PID 805 right now -


[ddipaolo@half-life ~]% ps ax | grep zsh 8:53AM [1005]
362 tty1 S 0:00 -zsh
805 pts/0 S 0:00 zsh
817 pts/0 S 0:00 grep zsh

(805 is the one I'm actually running out of this xterm, the first one is my login shell)

So, I can go into /proc/805/fd (fd = file descriptors, like STDIN, STDOUT, STDERR, sockets, actual files, etc.), and check out the open file descriptors for this process.


[ddipaolo@half-life /proc/805/fd]% ls -l
total 0
lrwx------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 0 -> /dev/pts/0
lrwx------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 1 -> /dev/pts/0
lrwx------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 10 -> /dev/pts/0
lr-x------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 12 -> /usr/share/zsh/4.0.2/functions/Completion.zwc
lr-x------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 13 -> /usr/share/zsh/4.0.2/functions/Completion/Zsh.zwc
lr-x------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 14 -> /usr/share/zsh/4.0.2/functions/Completion/Base.zwc
lr-x------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 15 -> /usr/share/zsh/4.0.2/functions/Completion/Unix.zwc
lrwx------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 2 -> /dev/pts/0
lr-x------ 1 ddipaolo ddipaolo 64 Aug 14 08:55 3 -> pipe:[1361915]

Normally, file descriptor 0 is STDOUT, file descriptor 1 is STDIN, and file descriptor 2 is STDERR. Let me open up a new xterm (pts/1) and redirect those symlinks to that device instead of pts/0 and see if that works ...

Hmm ...


half-life:/proc/805/fd# rm 0 1 2;ln -s /dev/pts/1 0;ln -s /dev/pts/1 1; ln -s /dev/pts/1 2
rm: cannot unlink `0': Operation not permitted
rm: cannot unlink `1': Operation not permitted
rm: cannot unlink `2': Operation not permitted
ln: `0': File exists
ln: `1': File exists
ln: `2': File exists

Oh well, you may get better results with a backgrounded process, but it was a nice idea :) See if you can improve upon it.

[TacKat]

Even better! I can't directly modify the /proc files because they're not normal files. BUT I can modify them if I get to the kernel's process table. This ought to be fun :)