1close(2)                      System Calls Manual                     close(2)
2
3
4

NAME

6       close - close a file descriptor
7

LIBRARY

9       Standard C library (libc, -lc)
10

SYNOPSIS

12       #include <unistd.h>
13
14       int close(int fd);
15

DESCRIPTION

17       close()  closes  a  file descriptor, so that it no longer refers to any
18       file and may be reused.  Any record locks (see fcntl(2))  held  on  the
19       file it was associated with, and owned by the process, are removed (re‐
20       gardless of the file descriptor that was used to obtain the lock).
21
22       If fd is the last file descriptor referring to the underlying open file
23       description  (see open(2)), the resources associated with the open file
24       description are freed; if the file descriptor was the last reference to
25       a file which has been removed using unlink(2), the file is deleted.
26

RETURN VALUE

28       close()  returns  zero on success.  On error, -1 is returned, and errno
29       is set to indicate the error.
30

ERRORS

32       EBADF  fd isn't a valid open file descriptor.
33
34       EINTR  The close() call was interrupted by a signal; see signal(7).
35
36       EIO    An I/O error occurred.
37
38       ENOSPC, EDQUOT
39              On NFS, these errors are not normally reported against the first
40              write  which  exceeds  the  available storage space, but instead
41              against a subsequent write(2), fsync(2), or close().
42
43       See NOTES for a discussion of why close() should not be  retried  after
44       an error.
45

STANDARDS

47       POSIX.1-2008.
48

HISTORY

50       POSIX.1-2001, SVr4, 4.3BSD.
51

NOTES

53       A  successful  close does not guarantee that the data has been success‐
54       fully saved to disk, as the kernel  uses  the  buffer  cache  to  defer
55       writes.   Typically,  filesystems  do  not flush buffers when a file is
56       closed.  If you need to be sure that the data is physically  stored  on
57       the  underlying  disk, use fsync(2).  (It will depend on the disk hard‐
58       ware at this point.)
59
60       The close-on-exec file descriptor flag can be used  to  ensure  that  a
61       file  descriptor  is  automatically closed upon a successful execve(2);
62       see fcntl(2) for details.
63
64   Multithreaded processes and close()
65       It is probably unwise to close file descriptors while they  may  be  in
66       use by system calls in other threads in the same process.  Since a file
67       descriptor may be reused, there are some obscure race  conditions  that
68       may cause unintended side effects.
69
70       When dealing with sockets, you have to be sure that there is no recv(2)
71       still blocking on it on another thread, otherwise it might  block  for‐
72       ever,  since  no  more messages will be send via the socket. Be sure to
73       use shutdown(2) to shut down all parts the  connection  before  closing
74       the socket.
75
76       Furthermore, consider the following scenario where two threads are per‐
77       forming operations on the same file descriptor:
78
79       (1)  One thread is blocked in an I/O system call on the  file  descrip‐
80            tor.   For example, it is trying to write(2) to a pipe that is al‐
81            ready full, or trying to read(2) from a stream socket  which  cur‐
82            rently has no available data.
83
84       (2)  Another thread closes the file descriptor.
85
86       The behavior in this situation varies across systems.  On some systems,
87       when the file descriptor is closed, the blocking  system  call  returns
88       immediately with an error.
89
90       On  Linux (and possibly some other systems), the behavior is different:
91       the blocking I/O system call holds a reference to the  underlying  open
92       file  description,  and this reference keeps the description open until
93       the I/O system call completes.  (See open(2) for a discussion  of  open
94       file descriptions.)  Thus, the blocking system call in the first thread
95       may successfully complete after the close() in the second thread.
96
97   Dealing with error returns from close()
98       A careful programmer will check the return value of close(),  since  it
99       is  quite possible that errors on a previous write(2) operation are re‐
100       ported only on the final close() that releases the open  file  descrip‐
101       tion.   Failing  to check the return value when closing a file may lead
102       to silent loss of data.  This can especially be observed with  NFS  and
103       with disk quota.
104
105       Note, however, that a failure return should be used only for diagnostic
106       purposes (i.e., a warning to the application that there  may  still  be
107       I/O  pending  or  there  may have been failed I/O) or remedial purposes
108       (e.g., writing the file once more or creating a backup).
109
110       Retrying the close() after a failure return is the wrong thing  to  do,
111       since this may cause a reused file descriptor from another thread to be
112       closed.  This can occur because the Linux kernel  always  releases  the
113       file descriptor early in the close operation, freeing it for reuse; the
114       steps that may return an error, such as flushing data to the filesystem
115       or device, occur only later in the close operation.
116
117       Many  other  implementations similarly always close the file descriptor
118       (except in the case of EBADF, meaning that the file descriptor was  in‐
119       valid)  even  if  they  subsequently  report  an  error  on return from
120       close().  POSIX.1 is currently silent on  this  point,  but  there  are
121       plans  to  mandate this behavior in the next major release of the stan‐
122       dard.
123
124       A careful programmer who wants to know about  I/O  errors  may  precede
125       close() with a call to fsync(2).
126
127       The EINTR error is a somewhat special case.  Regarding the EINTR error,
128       POSIX.1-2008 says:
129
130              If close() is interrupted by a signal that is to be  caught,  it
131              shall  return -1 with errno set to EINTR and the state of fildes
132              is unspecified.
133
134       This permits the behavior that occurs on Linux and many other implemen‐
135       tations,  where,  as with other errors that may be reported by close(),
136       the file descriptor is guaranteed to be closed.  However, it also  per‐
137       mits  another possibility: that the implementation returns an EINTR er‐
138       ror and keeps the file descriptor open.  (According to  its  documenta‐
139       tion,  HP-UX's  close() does this.)  The caller must then once more use
140       close() to close the file descriptor, to avoid file  descriptor  leaks.
141       This divergence in implementation behaviors provides a difficult hurdle
142       for portable applications, since on many implementations, close()  must
143       not  be called again after an EINTR error, and on at least one, close()
144       must be called again.  There are plans to address  this  conundrum  for
145       the next major release of the POSIX.1 standard.
146

SEE ALSO

148       close_range(2),  fcntl(2),  fsync(2),  open(2), shutdown(2), unlink(2),
149       fclose(3)
150
151
152
153Linux man-pages 6.05              2023-03-30                          close(2)
Impressum