linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Capturing output of a process.
@ 2003-12-18 20:36 Ramanan, Venkat (MED)
  2003-12-19  1:31 ` Glynn Clements
  0 siblings, 1 reply; 5+ messages in thread
From: Ramanan, Venkat (MED) @ 2003-12-18 20:36 UTC (permalink / raw)
  To: linux-c-programming

Hi all,

I have a newbie question which I am not sure whether it belongs here. But any help will be gratefully appreciated.

I know the process id of a process and its tty. I want to capture all the process's output (stdout and stderr)in a file. Assuming that I have root access, how can this be done? 

If I don't know the tty can I still get the output?

Thanks,
Venkat.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Capturing output of a process.
  2003-12-18 20:36 Capturing output of a process Ramanan, Venkat (MED)
@ 2003-12-19  1:31 ` Glynn Clements
  2003-12-19  5:05   ` Progga
  0 siblings, 1 reply; 5+ messages in thread
From: Glynn Clements @ 2003-12-19  1:31 UTC (permalink / raw)
  To: Ramanan, Venkat (MED); +Cc: linux-c-programming


Ramanan, Venkat \(MED\) wrote:

> I have a newbie question which I am not sure whether it belongs here. 
> But any help will be gratefully appreciated.
> 
> I know the process id of a process and its tty. I want to capture all
> the process's output (stdout and stderr)in a file. Assuming that I
> have root access, how can this be done?

It can't be done. Well, not easily. 

You could modify the kernel (almost anything can be done if you are
willing to modify the kernel). Or you could ptrace() the process and
intercept any system calls which write to the tty.

But there isn't any standard mechanism for "stealing" the data which
is written to a descriptor. Primarily because the kernel would have to
buffer the data until such time that the reader got around to reading
it. In turn, that would require that the kernel could either:

a) buffer an unlimited amount of data, or
b) suspend the writer until the reader removes some of the data from
the buffer.

Most practical solutions involve allocating a pseudo-tty *before*
starting the process whose output is to be logged.

-- 
Glynn Clements <glynn.clements@virgin.net>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Capturing output of a process.
  2003-12-19  1:31 ` Glynn Clements
@ 2003-12-19  5:05   ` Progga
  2003-12-19  8:59     ` Glynn Clements
  0 siblings, 1 reply; 5+ messages in thread
From: Progga @ 2003-12-19  5:05 UTC (permalink / raw)
  To: Glynn Clements; +Cc: linux-c-programming

On Fri, Dec 19, 2003 at 01:31:20AM +0000, Glynn Clements wrote:
 
> Most practical solutions involve allocating a pseudo-tty *before*
> starting the process whose output is to be logged.

 If I want to write something LIKE an SSL server, should I follow this same
technique to capture the output of a child process ?


 Khoda Hafez 
 Progga


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Capturing output of a process.
  2003-12-19  5:05   ` Progga
@ 2003-12-19  8:59     ` Glynn Clements
  0 siblings, 0 replies; 5+ messages in thread
From: Glynn Clements @ 2003-12-19  8:59 UTC (permalink / raw)
  To: Progga; +Cc: linux-c-programming


Progga wrote:

> > Most practical solutions involve allocating a pseudo-tty *before*
> > starting the process whose output is to be logged.
> 
>  If I want to write something LIKE an SSL server, should I follow this same
> technique to capture the output of a child process ?

If you want to provide anything resembling a login session, you need
to use a pseudo-tty. I.e. any situation where you need the facilities
of a tty (line discipline, process groups, job control etc), and can't
make do with just pipes or a socket.

This includes remote logins (ssh, telnet, rlogin etc), terminal
emulators (xterm, rxvt, screen etc), session capture (script etc).

All of these programs use the same basic mechanism: allocate a
pseudo-tty, fork() a child process with stdin/stdout/stderr connected
to the slave, while the program itself (sshd, xterm etc) reads/writes
the master.

Pseudo terminals get their own chapter in Stevens[1] (chapter 19),
although almost everything which applies to "real" terminals (chapters
9 (Process Relationships) and 11 (Terminal I/O)) also applies to
pseudo-terminals.

[1] Advanced Programming in the Unix(R) Environment
    W Richard Stevens
    Addison-Wesley

-- 
Glynn Clements <glynn.clements@virgin.net>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Capturing output of a process.
@ 2003-12-22 23:24 Ramanan, Venkat (MED)
  0 siblings, 0 replies; 5+ messages in thread
From: Ramanan, Venkat (MED) @ 2003-12-22 23:24 UTC (permalink / raw)
  To: Glynn Clements, linux-c-programming

Thanks Glynn for the clarification.

Thanks,
Venkat.

-----Original Message-----
From: Glynn Clements [mailto:glynn.clements@virgin.net]
Sent: Thursday, December 18, 2003 7:31 PM
To: Ramanan, Venkat (MED)
Cc: linux-c-programming@vger.kernel.org
Subject: Re: Capturing output of a process.



Ramanan, Venkat \(MED\) wrote:

> I have a newbie question which I am not sure whether it belongs here. 
> But any help will be gratefully appreciated.
> 
> I know the process id of a process and its tty. I want to capture all
> the process's output (stdout and stderr)in a file. Assuming that I
> have root access, how can this be done?

It can't be done. Well, not easily. 

You could modify the kernel (almost anything can be done if you are
willing to modify the kernel). Or you could ptrace() the process and
intercept any system calls which write to the tty.

But there isn't any standard mechanism for "stealing" the data which
is written to a descriptor. Primarily because the kernel would have to
buffer the data until such time that the reader got around to reading
it. In turn, that would require that the kernel could either:

a) buffer an unlimited amount of data, or
b) suspend the writer until the reader removes some of the data from
the buffer.

Most practical solutions involve allocating a pseudo-tty *before*
starting the process whose output is to be logged.

-- 
Glynn Clements <glynn.clements@virgin.net>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-12-22 23:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-18 20:36 Capturing output of a process Ramanan, Venkat (MED)
2003-12-19  1:31 ` Glynn Clements
2003-12-19  5:05   ` Progga
2003-12-19  8:59     ` Glynn Clements
  -- strict thread matches above, loose matches on Subject: below --
2003-12-22 23:24 Ramanan, Venkat (MED)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).