fd 0 == fd 1 when running under inetd?

fd 0 == fd 1 when running under inetd?

Post by Rahul Dhe » Wed, 31 Mar 1999 04:00:00

When a program is invoked from within inetd, it is assumed that stdin is
on file descriptor 0, and stdout is on file descriptor 1.

How safe is it for me to make the assumption that a program running
under inetd can simply use file descriptor 0 for both reads from stdin
and writes to stdout?

The specific project before me is to take a program that was written to
be a daemon that does all I/O to file descriptor 0, and run it under


1. read(fd, buf, size) after shutdown(fd, SHUT_RD) implementation-defined

I notice some missing specification in the documentation on shutdown():

The Linux man page and glibc info page say that shutdown(fd, SHUT_RD)
shuts off "reception" of data on the socket. Single Unix Spec says
"disables further receive operations". That sounds like it applies to the
tcp/ip session, not to the process's ability to read() if the socket
read buffer still has data when shutdown() is called. Neither the man
pages, info pages, or SuS man page say anything about what the
semantics of read() should be after shutdown(fd, SHUT_RD) is called.

The SO_LINGER option only discusses the write() direction: "close() and
shutdown() will block until all data has been written". (I wonder how
O_NONBLOCK works with that, but that's a question for another day).

An ipc tutorial from Berkeley's CSRG, issued when 4.3 bsd was the current bsd
version, says:

  Should a user have no use for any pending data, it may perform a
  "shutdown" on the socket prior to closing it. This call is of the

      shutdown(s, how);

  where "how" is 0 if the user is no longer interested in reading
  data, 1 if no more data will be sent, or 2 if no data is to be
  sent or received.

This appears to simply assume that code is not going to call read()
on the socket after shutdown(fd, SHUT_RD), and so leaves the question
of how the kernel is to respond to such a read() call undefined.
(Joys of an ad-hoc spec defined by the code that first implemented it,
and whose later formalization failed to specify the  semantics of subsequent
file operations on the socket fd after shutdown().)

So I would merely take the position that "results of read(fd, buf, size)
after shutdown(fd, SHUT_RD) has been called are implementation-defined"
(meaning that any given kernel will do something in that situation, but
code cannot expect how one kernel reacts to read() after
shutdown(fd, SHUT_RD) to be portable to other systems or kernel
versions without some formal standard specifying those semantics).

It seems prudent to not rely on the socket's read buffer to still be available
to the process after telling the kernel that you no longer have any
interest in reading from it. Anything the kernel does with the socket's
read buffer after shutdown(fd, SHUT_RD) is unspecified and thus valid
by definition.

How quickly the kernel gets around to actually notifying the remote peer
that the socket is closed for writing is internal to the tcp/ip stack.
"Immediately" would be good, but it is not going to be seen by the reader
that called shutdown() in any case.

Mutliple reader/writer apps that share a socket should still use locks and
"open/closed for i/o flags" (that are checked once a process or thread
holds the lock) to insulate themselves from variations in
(implementation-defined) "i/o after shutdown()" behavior, imho.


Clayton Weaver

"Everyone is ignorant, just about different things."  Will Rogers

2. Q: SCSI controller for MO drive

3. Is /dev/fd redundant to /proc/self/fd ?

4. Installation by sysinstall

5. g++ fd.getline() and msvc fd.getline()??

6. RH6.0: Really basic login question

7. PS2 MCA -> FD MCS-350 SCSI :: Compatible with other FD cards?

8. Motif 1.2.7 patch for Solaris X86 2.6? Where?

9. what is the fd of the socket of my server prog (started by inetd)?

10. Q inetd/sockets: how to run my daemon from inetd???

11. Meaning of "status of mouse fd"

12. simultaneous read & write on socket fd

13. How to Imcrease FD Size