NAME

       close - close a file descriptor

LIBRARY

       Standard C library (libc, -lc)

SYNOPSIS

       #include <unistd.h>

       int close(int fd);

DESCRIPTION

       close()  closes a file descriptor, so that it no longer refers to any file and may be reused.  Any record
       locks (see fcntl(2)) held on the file it was associated with, and  owned  by  the  process,  are  removed
       regardless  of  the  file  descriptor  that  was  used  to  obtain  the  lock.  This has some unfortunate
       consequences and one should be extra careful when  using  advisory  record  locking.   See  fcntl(2)  for
       discussion  of  the  risks and consequences as well as for the (probably preferred) open file description
       locks.

       If fd is the last file descriptor referring to the underlying open file description  (see  open(2)),  the
       resources  associated  with  the  open  file  description  are freed; if the file descriptor was the last
       reference to a file which has been removed using unlink(2), the file is deleted.

RETURN VALUE

       close() returns zero on success.  On error, -1 is returned, and errno is set to indicate the error.

ERRORS

       EBADF  fd isn't a valid open file descriptor.

       EINTR  The close() call was interrupted by a signal; see signal(7).

       EIO    An I/O error occurred.

       ENOSPC
       EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available
              storage space, but instead against a subsequent write(2), fsync(2), or close().

       See NOTES for a discussion of why close() should not be retried after an error.

STANDARDS

       POSIX.1-2008.

HISTORY

       POSIX.1-2001, SVr4, 4.3BSD.

NOTES

       A  successful  close  does not guarantee that the data has been successfully saved to disk, as the kernel
       uses the buffer cache to defer writes.  Typically, filesystems do  not  flush  buffers  when  a  file  is
       closed.   If you need to be sure that the data is physically stored on the underlying disk, use fsync(2).
       (It will depend on the disk hardware at this point.)

       The close-on-exec file descriptor flag can be used to ensure that  a  file  descriptor  is  automatically
       closed upon a successful execve(2); see fcntl(2) for details.

   Multithreaded processes and close()
       It is probably unwise to close file descriptors while they may be in use by system calls in other threads
       in the same process.  Since a file descriptor may be reused, there are some obscure race conditions  that
       may cause unintended side effects.

       Furthermore, consider the following scenario where two threads are performing operations on the same file
       descriptor:

       (1)  One thread is blocked in an I/O system call on the file descriptor.  For example, it  is  trying  to
            write(2)  to  a pipe that is already full, or trying to read(2) from a stream socket which currently
            has no available data.

       (2)  Another thread closes the file descriptor.

       The behavior in this situation varies across systems.  On some  systems,  when  the  file  descriptor  is
       closed, the blocking system call returns immediately with an error.

       On Linux (and possibly some other systems), the behavior is different: the blocking I/O system call holds
       a reference to the underlying open file description, and this reference keeps the description open  until
       the  I/O  system  call  completes.   (See open(2) for a discussion of open file descriptions.)  Thus, the
       blocking system call in the first thread may successfully  complete  after  the  close()  in  the  second
       thread.

   Dealing with error returns from close()
       A  careful programmer will check the return value of close(), since it is quite possible that errors on a
       previous write(2) operation are  reported  only  on  the  final  close()  that  releases  the  open  file
       description.   Failing  to  check  the  return value when closing a file may lead to silent loss of data.
       This can especially be observed with NFS and with disk quota.

       Note, however, that a failure return should be used only for diagnostic purposes (i.e., a warning to  the
       application  that  there may still be I/O pending or there may have been failed I/O) or remedial purposes
       (e.g., writing the file once more or creating a backup).

       Retrying the close() after a failure return is the wrong thing to do, since this may cause a reused  file
       descriptor from another thread to be closed.  This can occur because the Linux kernel always releases the
       file descriptor early in the close operation, freeing it for reuse; the steps that may return  an  error,
       such as flushing data to the filesystem or device, occur only later in the close operation.

       Many  other  implementations  similarly  always  close  the file descriptor (except in the case of EBADF,
       meaning that the file descriptor was invalid) even if they subsequently report an error  on  return  from
       close().   POSIX.1 is currently silent on this point, but there are plans to mandate this behavior in the
       next major release of the standard.

       A careful programmer who wants to know about I/O errors may precede close() with a call to fsync(2).

       The EINTR error is a somewhat special case.  Regarding the EINTR error, POSIX.1-2008 says:

              If close() is interrupted by a signal that is to be caught, it shall return -1 with errno  set  to
              EINTR and the state of fildes is unspecified.

       This  permits  the  behavior  that  occurs  on Linux and many other implementations, where, as with other
       errors that may be reported by close(), the file descriptor is guaranteed to be closed.  However, it also
       permits another possibility: that the implementation returns an EINTR error and keeps the file descriptor
       open.  (According to its documentation, HP-UX's close() does this.)  The caller must then once  more  use
       close()  to close the file descriptor, to avoid file descriptor leaks.  This divergence in implementation
       behaviors provides a difficult hurdle for portable applications, since on many  implementations,  close()
       must  not be called again after an EINTR error, and on at least one, close() must be called again.  There
       are plans to address this conundrum for the next major release of the POSIX.1 standard.

SEE ALSO

       close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3)