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>
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.
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.
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
23 .\" Formatted or processed versions of this manual, if unaccompanied by
24 .\" the source, must acknowledge the copyright and authors of this work.
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.
36 .TH CLOSE 2 2016-10-08 "Linux" "Linux Programmer's Manual"
38 close \- close a file descriptor
41 .B #include <unistd.h>
43 .BI "int close(int " fd );
47 closes a file descriptor, so that it no longer refers to any file and
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).
57 is the last file descriptor referring to the underlying
58 open file description (see
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
67 returns zero on success.
68 On error, \-1 is returned, and
75 isn't a valid open file descriptor.
80 call was interrupted by a signal; see
84 An I/O error occurred.
86 See NOTES for a discussion of why
88 should not be retried after an error.
90 POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
91 .\" SVr4 documents an additional ENOLINK error condition.
93 A careful programmer will check the return value of
95 since it is quite possible that errors on a previous
97 operation are reported only on the final
99 that releases the open file description.
100 Failing to check the return value when closing a file may lead to
103 This can especially be observed with NFS and with disk quota.
105 Note, however, that a failure return should be used only for
106 diagnostic purposes (i.e., a warning to the application that there
107 may still be I/O pending or there may have been failed I/O)
109 (e.g., writing the file once more or creating a backup).
113 after a failure return is the wrong thing to do,
114 .\" The file descriptor is released early in close();
115 .\" close() ==> __close_fd():
116 .\" __put_unused_fd() ==> __clear_open_fd()
117 .\" return filp_close(file, files);
119 .\" The errors are returned by filp_close() after the FD has been
120 .\" cleared for re-use.
121 since this may cause a reused file descriptor
122 from another thread to be closed.
123 This can occur because the Linux kernel
125 releases the file descriptor early in the close
126 operation, freeing it for reuse;
127 the steps that may return an error,
129 such as flushing data to the filesystem or device,
130 occur only later in the close operation.
132 Many other implementations similarly always close the file descriptor
133 .\" FreeBSD documents this explicitly. From the look of the source code
134 .\" SVR4, ancient SunOS, later Solaris, and AIX all do this.
135 (except in the case of
137 meaning that the file descriptor was invalid)
138 even if they subsequently report an error on return from
140 POSIX.1 is currently silent on this point,
141 but there are plans to mandate this behavior in the next major release
145 A careful programmer who wants to know about I/O errors may precede
152 error is a somewhat special case.
155 error, POSIX.1-2013 says:
160 is interrupted by a signal that is to be caught, it shall return \-1 with
169 This permits the behavior that occurs on Linux and
170 many other implementations, where,
171 as with other errors that may be reported by
173 the file descriptor is guaranteed to be closed.
174 However, it also permits another possibility:
175 that the implementation returns an
177 error and keeps the file descriptor open.
178 (According to its documentation, HP-UX's
181 The caller must then once more use
183 to close the file descriptor, to avoid file descriptor leaks.
184 This divergence in implementation behaviors provides
185 a difficult hurdle for portable applications, since on many implementations,
187 must not be called again after an
189 error, and on at least one,
191 must be called again.
192 There are plans to address this conundrum for
193 the next major release of the POSIX.1 standard.
194 .\" FIXME . for later review when Issue 8 is one day released...
195 .\" POSIX proposes further changes for EINTR
196 .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8
197 .\" http://austingroupbugs.net/view.php?id=529
200 .\" Review the following glibc bug later
201 .\" https://sourceware.org/bugzilla/show_bug.cgi?id=14627
203 A successful close does not guarantee that the data has been successfully
204 saved to disk, as the kernel uses the buffer cache to defer writes.
205 Typically, filesystems do not flush buffers when a file is closed.
206 If you need to be sure that
207 the data is physically stored on the underlying disk, use
209 (It will depend on the disk hardware at this point.)
211 The close-on-exec file descriptor flag can be used to ensure
212 that a file descriptor is automatically closed upon a successful
218 It is probably unwise to close file descriptors while
219 they may be in use by system calls in
220 other threads in the same process.
221 Since a file descriptor may be reused,
222 there are some obscure race conditions
223 that may cause unintended side effects.
224 .\" Date: Tue, 4 Sep 2007 13:57:35 +0200
225 .\" From: Fredrik Noring <noring@nocrew.org>
226 .\" One such race involves signals and ERESTARTSYS. If a file descriptor
227 .\" in use by a system call is closed and then reused by e.g. an
228 .\" independent open() in some unrelated thread, before the original system
229 .\" call has restarted after ERESTARTSYS, the original system call will
230 .\" later restart with the reused file descriptor. This is most likely a
231 .\" serious programming error.