Process control

You can try attaching to such process with gdb (or any other debugger).
However You may encounter such problem, that debug symbols are not compiled in(or stripped) and all You get would be memory addresses.
For less intrusive informations check /proc/PID/*

I know a lot of information can be found in /proc/PID but that is read only, right? Besides, is there an explanation of the contents available somewhere?

Attaching through gdb might work, but I don't want to interrupt the process. - I guess I'll have to study gdb a little bit further. And of course the program is compiled without debug information. - Maybe I can recompile it and load the symbols from the new file...?

Still, I can't change the process flags (like nohup) from gdb, can I?

man proc
> Maybe I can recompile it and load the symbols from the new file...?
Yes.

> Still, I can't change the process flags (like nohup) from gdb, can I?
What is the nohup flag??? First head of..

> What is the nohup flag??? First head of..
Well, I'll counter... man nohup ;-)

I know the command nohup - but there is no such process flag like nohup.

Ok... Then whatever nohup does (please tell me since I'm very curious), I want to be able to do (and undo).

nohup redirects stdin, stdout and stdin to file. Therefore while process is disconected from terminal, it still can read/write.
Then it sets SIGHUP handler to ignore.

Yes. It's the SIGHUP handler I'm looking for (I think). I don't think it's necessary at this point, but can I manipulate the redirects as well?

This kind of control of a process during runtime isn't available from outside --- if you run "nohup program";
the behavior of nohup is not accomplished by a mere process flag.

It is nohup itself that is immune to hangups ---  nohup doesn't modify the program it starts, sets up the
environment in a certain way - and starts the program up in that environment.

There is no easy way to accomplish exactly what nohup does without either modifying the program to
include nohup's features, OR to have run nohup in the first place.

To run the process with some Preloaded functions, entails that you have modified the program...
since you have to arrange the preloading before the program starts, it's not something you
can use to change a program you already started.

You could have just run "nohup program" beforehand, if you knew in advance...


You can run GDB and attach it to a running process, with
gdb /path/to/program
(gdb) attach <pid>

Suppose the program's PID is 12345...
Within GDB you can possibly redirect output to a file  or set SIGHUP to ignore by doing something like

shell$ gdb /path/to/program
(gdb) attach 12345
(gdb) call signal(1,1)
(gdb) call freopen("nohup.out", "a", stdout);
(gdb) call freopen("nohup.out", "a", stderr);
(gdb) detach



And no, you will not be able to reverse it with any simple command;  once you have made
another file descriptor the standard output  output file, there's really no method of
ascertaining the original output destination.

Ok. First part of my question is answered, I guess. How about the I/O queues? Can I (from gdb or anywhere else) see what has been written to stdout (primarily) and not yet been flushed? - Can I flush it from the outside?

Sorry for the delay. I guess I wanted more input at the beginning... Anyway, ravenpl helped me a lot with this one, so I think he deserves the score.