Proper way to close stdin, out, err

Proper way to close stdin, out, err

Post by The Great Mr. Kurtz [David A. Gatwood » Wed, 04 Jun 1997 04:00:00



Two questions:

1.
I've looked in the FAQ for a means to properly close stdin, stdout, and
stderr, without success.  The NUTS 2.3.0 sources just close the underlying
file descriptors (i.e. close(0);close(1);close(2);), but this leaves the
file pointers pointing to closed file descriptors which are then often
reused, and subsequent writes to them cause real problems.  I tried
assigning them NULL, even (FILE *)NULL, but get invalid lvalue in
assignment.  Is there anything wrong with doing a simple fclose(stdout);
fclose(stderr);  fclose(stdin); , and would that have the desired effect
of getting NULL or some other verifiable value stored in the relevant
pointers?

2.
This is the only reason that I could come up with for why a program could
be started from the command line, but when executed from another program
(background daemon with closed stdin, stdout, stderr), would suddenly
spike to 99% CPU utilization and not properly open any listen sockets,
etc....  If anybody knows of any other possible reasons for that, please
let me know as well.  :-)

Finally, thanks for the FAQ.  I was working on a web interface for the
talker, scratching my head, until I read the section on named pipes.  They
fit the bill perfectly, complete with being almost functionally identical
to telnet sockets (just don't log the user off if reading from the named
pipe returns 0, i.e. CGI program isn't running at that moment).  Very,
very helpful.  :-)

TIA,
David

 /---------------------------------------------------------------------\
|David A. Gatwood                    "My Head or my Heart...  that is   |


|-----------------------------------------------------------------------|
|http://globegate.utm.edu                  http://www.utm.edu/~davagatw |
|http://mars.utm.edu/~davagatw             http://www.nyx.net/~dgatwood |
 \---------------------------------------------------------------------/

 
 
 

Proper way to close stdin, out, err

Post by Andrew Giert » Wed, 04 Jun 1997 04:00:00


Quote:>>>>> "The" == The Great Mr Kurtz [David A Gatwood] <The> writes:

 The> I've looked in the FAQ for a means to properly close stdin,
 The> stdout, and stderr, without success.

It's rarely appropriate to close them and leave them closed. Better
technique is to point them at /dev/null:

  int fd = open("/dev/null",O_RDWR);
  if (fd < 0)
    /* die horribly; */

  if (fd != STDIN_FILENO)
  {
      dup2(fd,STDIN_FILENO);
      close(fd);
  }

  dup2(STDIN_FILENO,STDOUT_FILENO);
  dup2(STDIN_FILENO,STDERR_FILENO);

This works even if any or all of stdin/stdout/stderr were closed.

 The> This is the only reason that I could come up with for why a
 The> program could be started from the command line, but when
 The> executed from another program (background daemon with closed
 The> stdin, stdout, stderr), would suddenly spike to 99% CPU
 The> utilization and not properly open any listen sockets, etc....

Strong possibility, if it was looping on an EBADF somewhere.

Daemons shouldn't, on the whole, close stdin/stdout/stderr in any case
but point them to /dev/null or suitable files.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>

 
 
 

Proper way to close stdin, out, err

Post by Roger Espel Lli » Thu, 05 Jun 1997 04:00:00




Quote:>Daemons shouldn't, on the whole, close stdin/stdout/stderr in any case
>but point them to /dev/null or suitable files.

I've seen this before, and even followed the advice, but I can't quite
see why, actually...  if the daemon doesn't use stdio at all, why would
it need to keep stdio "happy" by making stdin, stdout and stderr point
to anything at all?  

are there bits of libc (other than stdio itself) that assume that these
work, like outputting messages to stderr?  and if the answer is yes,
couldn't this be considered broken?

        Roger
--

WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html

 
 
 

Proper way to close stdin, out, err

Post by Andrew Giert » Thu, 05 Jun 1997 04:00:00



 >> Daemons shouldn't, on the whole, close stdin/stdout/stderr in any case
 >> but point them to /dev/null or suitable files.

 Roger> I've seen this before, and even followed the advice, but I
 Roger> can't quite see why, actually...  if the daemon doesn't use
 Roger> stdio at all, why would it need to keep stdio "happy" by
 Roger> making stdin, stdout and stderr point to anything at all?

Fine if the daemon is self-contained. Once you start invoking other
programs, then you need to ensure that *they* have a consistent
environment.

 Roger> are there bits of libc (other than stdio itself) that assume
 Roger> that these work, like outputting messages to stderr?  and if
 Roger> the answer is yes, couldn't this be considered broken?

Not that I know of (except as documented effects, e.g. perror and
some syslog() implementations with LOG_PERROR).

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>

 
 
 

Proper way to close stdin, out, err

Post by Bjorn Ree » Thu, 05 Jun 1997 04:00:00




>  Roger> are there bits of libc (other than stdio itself) that assume
>  Roger> that these work, like outputting messages to stderr?  and if
>  Roger> the answer is yes, couldn't this be considered broken?
> Not that I know of (except as documented effects, e.g. perror and
> some syslog() implementations with LOG_PERROR).

Or if you decide to use a socket library (such as Socket++ which is
mentioned in the socket faq) which gladly use both perror() and
write to stderr (cerr) without documenting it.
 
 
 

1. How (many ways) can a shell script read stdin?

If you want a (bourne) script to read from standard input and when
data is received, run some command on that input, is there a "normal"
way to do that?

E.g., I want to write a script that will grep on standard input; I
don't want to run grep separately on each line, so what to do with the
results of "read"?

I wound up with:

    SCRATCH=/tmp/scratchpage.$$
    while read LINE
            do
            echo "$LINE" >> $SCRATCH
    done

And then grepping the file $SCRATCH.  Is that the normal way to do
this?  What if you didn't want it to have to wait for all data to be
received?  Can stdin be redirected to a pipe?

levin

2. GNU shellutils 1.9.2 available

3. stdin,out,err redirection

4. to grep some some value

5. Howto reassign stdin/out/err using fdopen()?

6. Anyone got Andrew Previewing/Printing working?

7. Cannot get VirtualButtons=3 mode under linux

8. avoiding deadlock processing child's stdin/out/err

9. Question about alloc/dealloc of tty lines and stdin/out/err

10. Sockets connections - proper way to close them?

11. closing stdin

12. Closing stdin after fork