Section (2) close
close — close a file descriptor
close() closes a file
descriptor, so that it no longer refers to any file and may
be reused. Any record locks (see fcntl(2)) held on the file
it was associated with, and owned by the process, are removed
(regardless of the file descriptor that was used to obtain
fd is the last
file descriptor referring to the underlying open file
description (see open(2)), the resources
associated with the open file description are freed; if the
file descriptor was the last reference to a file which has
been removed using unlink(2), the file is
close() returns zero on
success. On error, −1 is returned, and
errno is set appropriately.
fdisn_zsingle_quotesz_t a valid open file descriptor.
close() call was interrupted by a signal; see signal(7).
An I/O error occurred.
- ENOSPC, EDQUOT
See NOTES for a discussion of why
close() should not be retried after an
A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes. Typically, filesystems do not flush buffers when a file is closed. If you need to be sure that the data is physically stored on the underlying disk, use fsync(2). (It will depend on the disk hardware at this point.)
It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects.
Dealing with error returns from close()
A careful programmer will check the return value of
close(), since it is quite
possible that errors on a previous write(2) operation are
reported only on the final
close() that releases the open file
description. Failing to check the return value when closing
a file may lead to
silent loss of data. This
can especially be observed with NFS and with disk
Note, however, that a failure return should be used only for diagnostic purposes (i.e., a warning to the application that there may still be I/O pending or there may have been failed I/O) or remedial purposes (e.g., writing the file once more or creating a backup).
a failure return is the wrong thing to do, since this may
cause a reused file descriptor from another thread to be
closed. This can occur because the Linux kernel
always releases the file
descriptor early in the close operation, freeing it for
reuse; the steps that may return an error, such as flushing
data to the filesystem or device, occur only later in the
Many other implementations similarly always close the
file descriptor (except in the case of EBADF, meaning that the file descriptor
was invalid) even if they subsequently report an error on
is currently silent on this point, but there are plans to
mandate this behavior in the next major release of the
A careful programmer who wants to know about I/O errors
close() with a
call to fsync(2).
The EINTR error is a somewhat special case. Regarding the EINTR error, POSIX.1-2013 says:
close() is interrupted by a signal that is to be caught, it shall return −1 with
errnoset to EINTR and the state of
This permits the behavior that occurs on Linux and many
other implementations, where, as with other errors that may
be reported by
file descriptor is guaranteed to be closed. However, it
also permits another possibility: that the implementation
returns an EINTR error and
keeps the file descriptor open. (According to its
close() does this.) The caller must then
once more use
close the file descriptor, to avoid file descriptor leaks.
This divergence in implementation behaviors provides a
difficult hurdle for portable applications, since on many
not be called again after an EINTR error, and on at least one,
close() must be called again.
There are plans to address this conundrum for the next
major release of the POSIX.1 standard.
This page is part of release 5.04 of the Linux
man-pages project. A
description of the project, information about reporting bugs,
and the latest version of this page, can be found at
This manpage is Copyright (C) 1992 Drew Eckhardt;
and Copyright (C) 1993 Michael Haardt, Ian Jackson.
and Copyright (C) 2016 Michael Kerrisk <mtk.manpagesgmail.com>
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Since the Linux kernel and libraries are constantly changing, this
manual page may be incorrect or out-of-date. The author(s) assume no
responsibility for errors or omissions, or for damages resulting from
the use of the information contained herein. The author(s) may not
have taken the same level of care in the production of this manual,
which is licensed free of charge, as they might when working
Formatted or processed versions of this manual, if unaccompanied by
the source, must acknowledge the copyright and authors of this work.
Modified Wed Jul 21 22:40:25 1993 by Rik Faith <faithcs.unc.edu>
Modified Sat Feb 18 15:27:48 1995 by Michael Haardt
Modified Sun Apr 14 11:40:50 1996 by Andries Brouwer <aebcwi.nl>:
corrected description of effect on locks (thanks to
Tigran Aivazian <tigransco.com>).
Modified Fri Jan 31 16:21:46 1997 by Eric S. Raymond <esrthyrsus.com>
Modified 2000-07-22 by Nicolás Lichtmaier <nickdebian.org>
added note about close(2) not guaranteeing that data is safe on close.