close(2)                                                System Calls Manual                                                close(2)

       close - close a file descriptor

       Standard C library (libc, -lc)

       #include <unistd.h>

       int close(int fd);

       close()  closes  a  file  descriptor,  so that it no longer refers to any file and may be reused.  Any record locks (see fc‐
       ntl(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).

       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 us‐
       ing unlink(2), the file is deleted.

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

       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.

              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.

       POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.

       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  success‐
       ful 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  ef‐

       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 an‐
       other  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,  oc‐
       cur 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  re‐
       ported  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.

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

Linux man-pages 6.03                                         2022-10-30                                                    close(2)