1CLOSE(2)                   Linux Programmer's Manual                  CLOSE(2)
2
3
4

NAME

6       close - close a file descriptor
7

SYNOPSIS

9       #include <unistd.h>
10
11       int close(int fd);
12

DESCRIPTION

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
17       (regardless of the file descriptor that was used to obtain the lock).
18
19       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

RETURN VALUE

25       close()  returns  zero on success.  On error, -1 is returned, and errno
26       is set appropriately.
27

ERRORS

29       EBADF  fd isn't a valid open file descriptor.
30
31       EINTR  The close() call was interrupted by a signal; see signal(7).
32
33       EIO    An I/O error occurred.
34
35       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
40       See NOTES for a discussion of why close() should not be  retried  after
41       an error.
42

CONFORMING TO

44       POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
45

NOTES

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
54       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
58       It is probably unwise to close file descriptors while they  may  be  in
59       use by system calls in other threads in the same process.  Since a file
60       descriptor may be reused, there are some obscure race  conditions  that
61       may cause unintended side effects.
62
63       When dealing with sockets, you have to be sure that there is no recv(2)
64       still blocking on it on another thread, otherwise it might  block  for‐
65       ever,  since  no  more messages will be send via the socket. Be sure to
66       use shutdown(2) to shut down all parts the  connection  before  closing
67       the socket.
68
69   Dealing with error returns from close()
70       A  careful  programmer will check the return value of close(), since it
71       is quite possible that errors on  a  previous  write(2)  operation  are
72       reported only on the final close() that releases the open file descrip‐
73       tion.  Failing to check the return value when closing a file  may  lead
74       to  silent  loss of data.  This can especially be observed with NFS and
75       with disk quota.
76
77       Note, however, that a failure return should be used only for diagnostic
78       purposes  (i.e.,  a  warning to the application that there may still be
79       I/O pending or there may have been failed  I/O)  or  remedial  purposes
80       (e.g., writing the file once more or creating a backup).
81
82       Retrying  the  close() after a failure return is the wrong thing to do,
83       since this may cause a reused file descriptor from another thread to be
84       closed.   This  can  occur because the Linux kernel always releases the
85       file descriptor early in the close operation, freeing it for reuse; the
86       steps that may return an error, such as flushing data to the filesystem
87       or device, occur only later in the close operation.
88
89       Many other implementations similarly always close the  file  descriptor
90       (except  in  the  case  of  EBADF, meaning that the file descriptor was
91       invalid) even if they subsequently  report  an  error  on  return  from
92       close().   POSIX.1  is  currently  silent  on this point, but there are
93       plans to mandate this behavior in the next major release of  the  stan‐
94       dard.
95
96       A  careful  programmer  who  wants to know about I/O errors may precede
97       close() with a call to fsync(2).
98
99       The EINTR error is a somewhat special case.  Regarding the EINTR error,
100       POSIX.1-2013 says:
101
102              If  close()  is interrupted by a signal that is to be caught, it
103              shall return -1 with errno set to EINTR and the state of  fildes
104              is unspecified.
105
106       This permits the behavior that occurs on Linux and many other implemen‐
107       tations, where, as with other errors that may be reported  by  close(),
108       the  file descriptor is guaranteed to be closed.  However, it also per‐
109       mits another possibility: that  the  implementation  returns  an  EINTR
110       error and keeps the file descriptor open.  (According to its documenta‐
111       tion, HP-UX's close() does this.)  The caller must then once  more  use
112       close()  to  close the file descriptor, to avoid file descriptor leaks.
113       This divergence in implementation behaviors provides a difficult hurdle
114       for  portable applications, since on many implementations, close() must
115       not be called again after an EINTR error, and on at least one,  close()
116       must  be  called  again.  There are plans to address this conundrum for
117       the next major release of the POSIX.1 standard.
118

SEE ALSO

120       fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3)
121

COLOPHON

123       This page is part of release 5.04 of the Linux  man-pages  project.   A
124       description  of  the project, information about reporting bugs, and the
125       latest    version    of    this    page,    can     be     found     at
126       https://www.kernel.org/doc/man-pages/.
127
128
129
130Linux                             2019-10-10                          CLOSE(2)
Impressum