2

A daemon process, on detecting the presence of a text file in a particular directory then launches an executable file which opens the aforementioned text file in order to read and then transmit its data over a TCP socket.

The number of the file descriptor of the opened text file is logged along with other information about the processing of the file.

It has been noticed that from time to time, the file descriptor returned by the open() call is zero (normally this is reserved for stdin). No error is detected and all works well. The source code in C does nothing more that open() and later close() - there is no redirection, duplication or any other wizardry performed on the returned file handle.

Under what circumstances could a process's file descriptor 0 be available for general use (and not attributed to stdin) ?

Platform is AIX 5.2.

0

Under what circumstances could a process's file descriptor 0 be available for general use (and not attributed to stdin)

When somebody has closed stdin, e.g. with <&- from the shell.

#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
int main() {
    printf("%d\n",open("foo",O_CREAT));
}
  • This is good information, thank you. I did the following test: I closed stdin with "exec 0<&-" (by the way, running simply "0<&-" immediately closed me out of my bash shell). I then ran the above compiled C code, but it consistently returned "3" instead of the now presumably available 0 as a filehandle. Is my test incorrect? – Wheelnut Nov 12 '13 at 21:00
  • Each process has its own i/o descriptors. Close the shell's input, it quits. To run the above program with a closed input, run it with e.g. ./fd0 <&-. – jthill Nov 12 '13 at 21:12
1

The open system call typically returns the lowest file descriptor that isn't already in use. For typical programs, open files start at 3 because file descriptors 0, 1 and 2 are used for the pre-opened standard descriptors (input, output and error). Daemon will never read any input or produce any output, so they typically close file descriptors 0 and 1, or reopen /dev/null there. If the daemon closes file descriptor 0 then the next file it opens will be on that descriptor. There's nothing wrong with this.

File descriptor 0 isn't really “attributed to stdin” — rather, it is stdin by definition of stdin. Normal run environments arrange to have file descriptor 0 open for input, but a program that doesn't read any input is free to use that descriptor for whatever purpose it wants.

  • Re: there's nothing wrong. Daemons should really open either "/dev/null" or a logger on file descriptors 1 and 2 before execve'ing other programs. Otherwise, you may end up with log output on data files. Bear in mind that even if the program doesn't appear to output anything to std{out,err}, libraries may. Even glibc can output to stderr if LIBC_FATAL_STDERR_ is set ot if it cannot open "/dev/tty". – ninjalj Nov 11 '13 at 16:43
  • @ninjalj On fd 2, yes. But on fd 0, I don't see any reason. Any file opened by a daemon should be closed before executing an unrelated process regardless of the descriptor. – Gilles Nov 11 '13 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.