man2/close.2

   1 .\" This manpage is Copyright (C) 1992 Drew Eckhardt;
   2 .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson.
   3 .\" and Copyright (C) 2016 Michael Kerrisk <mtk.manpages@gmail.com>
   4 .\"
   5 .\" %%%LICENSE_START(VERBATIM)
   6 .\" Permission is granted to make and distribute verbatim copies of this
   7 .\" manual provided the copyright notice and this permission notice are
   8 .\" preserved on all copies.
   9 .\"
  10 .\" Permission is granted to copy and distribute modified versions of this
  11 .\" manual under the conditions for verbatim copying, provided that the
  12 .\" entire resulting derived work is distributed under the terms of a
  13 .\" permission notice identical to this one.
  14 .\"
  15 .\" Since the Linux kernel and libraries are constantly changing, this
  16 .\" manual page may be incorrect or out-of-date.  The author(s) assume no
  17 .\" responsibility for errors or omissions, or for damages resulting from
  18 .\" the use of the information contained herein.  The author(s) may not
  19 .\" have taken the same level of care in the production of this manual,
  20 .\" which is licensed free of charge, as they might when working
  21 .\" professionally.
  22 .\"
  23 .\" Formatted or processed versions of this manual, if unaccompanied by
  24 .\" the source, must acknowledge the copyright and authors of this work.
  25 .\" %%%LICENSE_END
  26 .\"
  27 .\" Modified Wed Jul 21 22:40:25 1993 by Rik Faith <faith@cs.unc.edu>
  28 .\" Modified Sat Feb 18 15:27:48 1995 by Michael Haardt
  29 .\" Modified Sun Apr 14 11:40:50 1996 by Andries Brouwer <aeb@cwi.nl>:
  30 .\"   corrected description of effect on locks (thanks to
  31 .\"   Tigran Aivazian <tigran@sco.com>).
  32 .\" Modified Fri Jan 31 16:21:46 1997 by Eric S. Raymond <esr@thyrsus.com>
  33 .\" Modified 2000-07-22 by Nicolás Lichtmaier <nick@debian.org>
  34 .\"   added note about close(2) not guaranteeing that data is safe on close.
  35 .\"
  36 .TH CLOSE 2 2017-09-15 "Linux" "Linux Programmer's Manual"
  37 .SH NAME
  38 close \- close a file descriptor
  39 .SH SYNOPSIS
  40 .nf
  41 .B #include <unistd.h>
  42 .PP
  43 .BI "int close(int " fd );
  44 .fi
  45 .SH DESCRIPTION
  46 .BR close ()
  47 closes a file descriptor, so that it no longer refers to any file and
  48 may be reused.
  49 Any record locks (see
  50 .BR fcntl (2))
  51 held on the file it was associated with,
  52 and owned by the process, are removed (regardless of the file
  53 descriptor that was used to obtain the lock).
  54 .PP
  55 If
  56 .I fd
  57 is the last file descriptor referring to the underlying
  58 open file description (see
  59 .BR open (2)),
  60 the resources associated with the open file description are freed;
  61 if the file descriptor was the last reference to a file which has been
  62 removed using
  63 .BR unlink (2),
  64 the file is deleted.
  65 .SH RETURN VALUE
  66 .BR close ()
  67 returns zero on success.
  68 On error, \-1 is returned, and
  69 .I errno
  70 is set appropriately.
  71 .SH ERRORS
  72 .TP
  73 .B EBADF
  74 .I fd
  75 isn't a valid open file descriptor.
  76 .TP
  77 .B EINTR
  78 The
  79 .BR close ()
  80 call was interrupted by a signal; see
  81 .BR signal (7).
  82 .TP
  83 .B EIO
  84 An I/O error occurred.
  85 .TP
  86 .BR ENOSPC ", " EDQUOT
  87 On NFS, these errors are not normally reported against the first write
  88 which exceeds the available storage space, but instead against a
  89 subsequent
  90 .BR write (2),
  91 .BR fsync (2),
  92 or
  93 .BR close (2).
  94 .PP
  95 See NOTES for a discussion of why
  96 .BR close ()
  97 should not be retried after an error.
  98 .SH CONFORMING TO
  99 POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
 100 .\" SVr4 documents an additional ENOLINK error condition.
 101 .SH NOTES
 102 A successful close does not guarantee that the data has been successfully
 103 saved to disk, as the kernel uses the buffer cache to defer writes.
 104 Typically, filesystems do not flush buffers when a file is closed.
 105 If you need to be sure that
 106 the data is physically stored on the underlying disk, use
 107 .BR fsync (2).
 108 (It will depend on the disk hardware at this point.)
 109 .PP
 110 The close-on-exec file descriptor flag can be used to ensure
 111 that a file descriptor is automatically closed upon a successful
 112 .BR execve (2);
 113 see
 114 .BR fcntl (2)
 115 for details.
 116 .PP
 117 It is probably unwise to close file descriptors while
 118 they may be in use by system calls in
 119 other threads in the same process.
 120 Since a file descriptor may be reused,
 121 there are some obscure race conditions
 122 that may cause unintended side effects.
 123 .\" Date: Tue, 4 Sep 2007 13:57:35 +0200
 124 .\" From: Fredrik Noring <noring@nocrew.org>
 125 .\" One such race involves signals and ERESTARTSYS. If a file descriptor
 126 .\" in use by a system call is closed and then reused by e.g. an
 127 .\" independent open() in some unrelated thread, before the original system
 128 .\" call has restarted after ERESTARTSYS, the original system call will
 129 .\" later restart with the reused file descriptor. This is most likely a
 130 .\" serious programming error.
 131 .\"
 132 .SS Dealing with error returns from close()
 133 A careful programmer will check the return value of
 134 .BR close (),
 135 since it is quite possible that errors on a previous
 136 .BR write (2)
 137 operation are reported only on the final
 138 .BR close ()
 139 that releases the open file description.
 140 Failing to check the return value when closing a file may lead to
 141 .I silent
 142 loss of data.
 143 This can especially be observed with NFS and with disk quota.
 144 .PP
 145 Note, however, that a failure return should be used only for
 146 diagnostic purposes (i.e., a warning to the application that there
 147 may still be I/O pending or there may have been failed I/O)
 148 or remedial purposes
 149 (e.g., writing the file once more or creating a backup).
 150 .PP
 151 Retrying the
 152 .BR close ()
 153 after a failure return is the wrong thing to do,
 154 .\" The file descriptor is released early in close();
 155 .\" close() ==> __close_fd():
 156 .\"                     __put_unused_fd() ==> __clear_open_fd()
 157 .\"                     return filp_close(file, files);
 158 .\"
 159 .\" The errors are returned by filp_close() after the FD has been
 160 .\" cleared for re-use.
 161 since this may cause a reused file descriptor
 162 from another thread to be closed.
 163 This can occur because the Linux kernel
 164 .I always
 165 releases the file descriptor early in the close
 166 operation, freeing it for reuse;
 167 the steps that may return an error,
 168 .\" filp_close()
 169 such as flushing data to the filesystem or device,
 170 occur only later in the close operation.
 171 .PP
 172 Many other implementations similarly always close the file descriptor
 173 .\" FreeBSD documents this explicitly. From the look of the source code
 174 .\" SVR4, ancient SunOS, later Solaris, and AIX all do this.
 175 (except in the case of
 176 .BR EBADF ,
 177 meaning that the file descriptor was invalid)
 178 even if they subsequently report an error on return from
 179 .BR close ().
 180 POSIX.1 is currently silent on this point,
 181 but there are plans to mandate this behavior in the next major release
 182 .\" Issue 8
 183 of the standard.
 184 .PP
 185 A careful programmer who wants to know about I/O errors may precede
 186 .BR close ()
 187 with a call to
 188 .BR fsync (2).
 189 .PP
 190 The
 191 .B EINTR
 192 error is a somewhat special case.
 193 Regarding the
 194 .B EINTR
 195 error, POSIX.1-2013 says:
 196 .PP
 197 .RS
 198 If
 199 .BR close ()
 200 is interrupted by a signal that is to be caught, it shall return \-1 with
 201 .I errno
 202 set to
 203 .B EINTR
 204 and the state of
 205 .I fildes
 206 is unspecified.
 207 .RE
 208 .PP
 209 This permits the behavior that occurs on Linux and
 210 many other implementations, where,
 211 as with other errors that may be reported by
 212 .BR close (),
 213 the file descriptor is guaranteed to be closed.
 214 However, it also permits another possibility:
 215 that the implementation returns an
 216 .B EINTR
 217 error and keeps the file descriptor open.
 218 (According to its documentation, HP-UX's
 219 .BR close ()
 220 does this.)
 221 The caller must then once more use
 222 .BR close ()
 223 to close the file descriptor, to avoid file descriptor leaks.
 224 This divergence in implementation behaviors provides
 225 a difficult hurdle for portable applications, since on many implementations,
 226 .BR close ()
 227 must not be called again after an
 228 .B EINTR
 229 error, and on at least one,
 230 .BR close ()
 231 must be called again.
 232 There are plans to address this conundrum for
 233 the next major release of the POSIX.1 standard.
 234 .\" FIXME . for later review when Issue 8 is one day released...
 235 .\" POSIX proposes further changes for EINTR
 236 .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8
 237 .\" http://austingroupbugs.net/view.php?id=529
 238 .\"
 239 .\" FIXME .
 240 .\" Review the following glibc bug later
 241 .\" https://sourceware.org/bugzilla/show_bug.cgi?id=14627
 242 .SH SEE ALSO
 243 .BR fcntl (2),
 244 .BR fsync (2),
 245 .BR open (2),
 246 .BR shutdown (2),
 247 .BR unlink (2),
 248 .BR fclose (3)