close(2)
Canonical URL: /close.2/
NAME
close —
delete a descriptor
SYNOPSIS
#include
<unistd.h>
int
close(int
d);
DESCRIPTION
The
close()
call deletes a descriptor d from the per-process
object reference table. If this is the last reference to the underlying
object, the object will be deactivated. For example, on the last close of a
file, the current
seek
pointer associated with the file is lost; on the last close of a
socket(2), associated
naming information and queued data are discarded; and on the last close of a
file holding an advisory lock, the lock is released (see
flock(2)). However, the
semantics of System V and IEEE Std 1003.1-1988
(“POSIX.1”) dictate that all
fcntl(2) advisory record
locks associated with a file for a given process are removed when
any file
descriptor for that file is closed by that process.
When a process forks (see
fork(2)), all descriptors for
the new child process reference the same objects as they did in the parent
before the fork. If a new process image is to then be run using
execve(2), the process
would normally inherit these descriptors. Most of the descriptors can be
rearranged with dup2(2) or
deleted with
close()
before the execve(2) is
attempted, but since some of these descriptors may still be needed should
the execve(2) fail, it is
necessary to arrange for them to be closed when the
execve(2) succeeds. For
this reason, the call
fcntl(d,
F_SETFD, FD_CLOEXEC) is
provided, which arranges that a descriptor will be closed after a successful
execve(2); the call
fcntl(d,
F_SETFD, 0) restores the
default, which is to not close the descriptor.
RETURN VALUES
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error.
ERRORS
close() will fail if:
SEE ALSO
accept(2), closefrom(2), dup2(2), execve(2), fcntl(2), flock(2), open(2), pipe(2), socket(2), socketpair(2)
STANDARDS
close() conforms to IEEE
Std 1003.1-2008 (“POSIX.1”).
HISTORY
The close() system call first appeared in
Version 1 AT&T UNIX.
Need conceptual guidance? Continue in the OpenBSD Handbook.