1CLOSE(2) Linux Programmer's Manual CLOSE(2)
2
6 close - close a file descriptor
7
9 #include <unistd.h>
10 int close(int fd);
12
14 close() closes a file descriptor, so that it no longer refers to any
15 file and may be reused. Any record locks (see fcntl(2)) held on the
16 file it was associated with, and owned by the process, are removed (re‐
17 gardless of the file descriptor that was used to obtain the lock).
18 If fd is the last file descriptor referring to the underlying open file
20 description (see open(2)), the resources associated with the open file
21 description are freed; if the file descriptor was the last reference to
22 a file which has been removed using unlink(2), the file is deleted.
23
25 close() returns zero on success. On error, -1 is returned, and errno
26 is set to indicate the error.
27
29 EBADF fd isn't a valid open file descriptor.
30 EINTR The close() call was interrupted by a signal; see signal(7).
32 EIO An I/O error occurred.
34 ENOSPC, EDQUOT
36 On NFS, these errors are not normally reported against the first
37 write which exceeds the available storage space, but instead
38 against a subsequent write(2), fsync(2), or close().
39 See NOTES for a discussion of why close() should not be retried after
41 an error.
42
44 POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
45
47 A successful close does not guarantee that the data has been success‐
48 fully saved to disk, as the kernel uses the buffer cache to defer
49 writes. Typically, filesystems do not flush buffers when a file is
50 closed. If you need to be sure that the data is physically stored on
51 the underlying disk, use fsync(2). (It will depend on the disk hard‐
52 ware at this point.)
53 The close-on-exec file descriptor flag can be used to ensure that a
55 file descriptor is automatically closed upon a successful execve(2);
56 see fcntl(2) for details.
57 Multithreaded processes and close()
59 It is probably unwise to close file descriptors while they may be in
60 use by system calls in other threads in the same process. Since a file
61 descriptor may be reused, there are some obscure race conditions that
62 may cause unintended side effects.
63 When dealing with sockets, you have to be sure that there is no recv(2)
65 still blocking on it on another thread, otherwise it might block for‐
66 ever, since no more messages will be send via the socket. Be sure to
67 use shutdown(2) to shut down all parts the connection before closing
68 the socket.
69 Furthermore, consider the following scenario where two threads are per‐
71 forming operations on the same file descriptor:
72 1. One thread is blocked in an I/O system call on the file descriptor.
74 For example, it is trying to write(2) to a pipe that is already
75 full, or trying to read(2) from a stream socket which currently has
76 no available data.
77 2. Another thread closes the file descriptor.
79 The behavior in this situation varies across systems. On some systems,
81 when the file descriptor is closed, the blocking system call returns
82 immediately with an error.
83 On Linux (and possibly some other systems), the behavior is different:
85 the blocking I/O system call holds a reference to the underlying open
86 file description, and this reference keeps the description open until
87 the I/O system call completes. (See open(2) for a discussion of open
88 file descriptions.) Thus, the blocking system call in the first thread
89 may successfully complete after the close() in the second thread.
90 Dealing with error returns from close()
92 A careful programmer will check the return value of close(), since it
93 is quite possible that errors on a previous write(2) operation are re‐
94 ported only on the final close() that releases the open file descrip‐
95 tion. Failing to check the return value when closing a file may lead
96 to silent loss of data. This can especially be observed with NFS and
97 with disk quota.
98 Note, however, that a failure return should be used only for diagnostic
100 purposes (i.e., a warning to the application that there may still be
101 I/O pending or there may have been failed I/O) or remedial purposes
102 (e.g., writing the file once more or creating a backup).
103 Retrying the close() after a failure return is the wrong thing to do,
105 since this may cause a reused file descriptor from another thread to be
106 closed. This can occur because the Linux kernel always releases the
107 file descriptor early in the close operation, freeing it for reuse; the
108 steps that may return an error, such as flushing data to the filesystem
109 or device, occur only later in the close operation.
110 Many other implementations similarly always close the file descriptor
112 (except in the case of EBADF, meaning that the file descriptor was in‐
113 valid) even if they subsequently report an error on return from
114 close(). POSIX.1 is currently silent on this point, but there are
115 plans to mandate this behavior in the next major release of the stan‐
116 dard.
117 A careful programmer who wants to know about I/O errors may precede
119 close() with a call to fsync(2).
120 The EINTR error is a somewhat special case. Regarding the EINTR error,
122 POSIX.1-2008 says:
123 If close() is interrupted by a signal that is to be caught, it
125 shall return -1 with errno set to EINTR and the state of fildes
126 is unspecified.
127 This permits the behavior that occurs on Linux and many other implemen‐
129 tations, where, as with other errors that may be reported by close(),
130 the file descriptor is guaranteed to be closed. However, it also per‐
131 mits another possibility: that the implementation returns an EINTR er‐
132 ror and keeps the file descriptor open. (According to its documenta‐
133 tion, HP-UX's close() does this.) The caller must then once more use
134 close() to close the file descriptor, to avoid file descriptor leaks.
135 This divergence in implementation behaviors provides a difficult hurdle
136 for portable applications, since on many implementations, close() must
137 not be called again after an EINTR error, and on at least one, close()
138 must be called again. There are plans to address this conundrum for
139 the next major release of the POSIX.1 standard.
140
142 close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2),
143 fclose(3)
144
146 This page is part of release 5.13 of the Linux man-pages project. A
147 description of the project, information about reporting bugs, and the
148 latest version of this page, can be found at
149 https://www.kernel.org/doc/man-pages/.
150Linux 2021-03-22 CLOSE(2)