1

I presume that (x)inetd works like most daemons, in that when it accept()s a connection on a port it's monitoring, a socket is created. Somehow, though, before it fork()s and exec()s the target service program, it manages to convert this bidirectional socket into the three standard I/O descriptors STDIN, STDOUT, and STDERR.

I've been asking around how to defeat this behavior without rolling my own version of inetd, with no success. It occurred to me to ask the question in this manner, because it might lend a clue as to how I might then re-"join" file descriptors 0, 1, and 2 into a single socket.

The reason for my wanting to have the service program communicate bidirectionally over a single socket is that it needs to use an I/O infrastructure that is based on a single, bidirectional socket.

Chap
  • 3,649
  • 2
  • 46
  • 84
  • How sure are you that fds 0, 1, and 2 are not all simply referring to the same underlying socket? – Greg Hewgill Aug 12 '13 at 05:25
  • Well ... I'm not. But it's not possible to choose one and use it bidirectionally - writing to STDIN, for instance, raises an error; I think to the effect that the descriptor is closed for writing. – Chap Aug 12 '13 at 05:34
  • Hmm. Not sure what's going on there, I haven't really worked on code that needs to run under inetd. But as with all things unix, what is going on is probably simpler than you imagine. :) – Greg Hewgill Aug 12 '13 at 05:37

1 Answers1

0

Incoming data to the inet.d server will be mapped to stdin, and fprintf(stdout) & fprintf(stderr) of inet.d handler will be send back to client by combining into one stream.

Here the issue is telnet client can't distinguish the stdout and stderr streams. If needed use ssh instead of telnet, that provides the option.

Arunprasad Rajkumar
  • 1,374
  • 1
  • 15
  • 31