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