CLOSE(2)		   Linux Programmer's Manual		      CLOSE(2)



NAME
       close - close a file descriptor

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

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

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.

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

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

NOTES
       A  successful  close does not guarantee that the data has been success-
       fully 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 hard-
       ware 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.

       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.

       When dealing with sockets, you have to be sure that there is no recv(2)
       still blocking on it on another thread, otherwise it might  block  for-
       ever,  since  no	 more messages will be send via the socket. Be sure to
       use shutdown(2) to shut down all parts the  connection  before  closing
       the socket.

   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 descrip-
       tion.  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	 stan-
       dard

       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-2013 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 implemen-
       tations, where, as with other errors that may be reported  by  close(),
       the  file descriptor is guaranteed to be closed.	 However, it also per-
       mits another possibility: that  the  implementation  returns  an	 EINTR
       error and keeps the file descriptor open.  (According to its documenta-
       tion, 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
       fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3)

COLOPHON
       This page is part of release 4.10 of the Linux  man-pages  project.   A
       description  of	the project, information about reporting bugs, and the
       latest	 version    of	  this	  page,	   can	   be	  found	    at
       https://www.kernel.org/doc/man-pages/.



Linux				  2016-10-08			      CLOSE(2)