# close

## 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.
    


## 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.
    


* * *