close man page on Archlinux

Man page or keyword search:  
man Server   11224 pages
apropos Keyword Search (all sections)
Output format
Archlinux logo
[printable version]

CLOSE(3P)		   POSIX Programmer's Manual		     CLOSE(3P)

       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
       implementation of this interface may differ (consult the	 corresponding
       Linux  manual page for details of Linux behavior), or the interface may
       not be implemented on Linux.

       closeclose a file descriptor

       #include <unistd.h>

       int close(int fildes);

       The close() function shall deallocate the file descriptor indicated  by
       fildes.	 To deallocate means to make the file descriptor available for
       return by subsequent calls to open() or other functions	that  allocate
       file  descriptors. All outstanding record locks owned by the process on
       the file associated with the file descriptor shall be removed (that is,

       If  close()  is	interrupted by a signal that is to be caught, it shall
       return −1 with errno set to [EINTR] and the state of fildes is unspeci‐
       fied.  If  an  I/O  error occurred while reading from or writing to the
       file system during close(), it may return −1 with errno set  to	[EIO];
       if this error is returned, the state of fildes is unspecified.

       When  all  file descriptors associated with a pipe or FIFO special file
       are closed, any data remaining in the pipe or FIFO shall be discarded.

       When all file descriptors associated with an open file description have
       been closed, the open file description shall be freed.

       If  the	link count of the file is 0, when all file descriptors associ‐
       ated with the file are closed, the space occupied by the file shall  be
       freed and the file shall no longer be accessible.

       If  a STREAMS-based fildes is closed and the calling process was previ‐
       ously registered to receive a SIGPOLL signal for events associated with
       that STREAM, the calling process shall be unregistered for events asso‐
       ciated with the STREAM. The last close() for a STREAM shall  cause  the
       STREAM  associated  with	 fildes to be dismantled. If O_NONBLOCK is not
       set and there have been no signals posted for the STREAM, and if	 there
       is data on the module's write queue, close() shall wait for an unspeci‐
       fied time (for each module and driver) for any output to	 drain	before
       dismantling  the	 STREAM.  The  time delay can be changed via an I_SET‐
       CLTIME ioctl() request. If the O_NONBLOCK flag is set, or if there  are
       any  pending  signals,  close() shall not wait for output to drain, and
       shall dismantle the STREAM immediately.

       If the implementation supports STREAMS-based pipes, and fildes is asso‐
       ciated with one end of a pipe, the last close() shall cause a hangup to
       occur on the other end of the pipe. In addition, if the	other  end  of
       the pipe has been named by fattach(), then the last close() shall force
       the named end to be detached by fdetach().  If the  named  end  has  no
       open  file descriptors associated with it and gets detached, the STREAM
       associated with that end shall also be dismantled.

       If fildes refers to the master side of a pseudo-terminal, and  this  is
       the  last  close,  a  SIGHUP  signal  shall  be sent to the controlling
       process, if any, for which the slave side of the pseudo-terminal is the
       controlling terminal. It is unspecified whether closing the master side
       of the pseudo-terminal flushes all queued input and output.

       If fildes refers to the slave side of a STREAMS-based  pseudo-terminal,
       a zero-length message may be sent to the master.

       When  there  is	an  outstanding	 cancelable asynchronous I/O operation
       against fildes when close() is called, that I/O operation may  be  can‐
       celed.  An  I/O	operation  that	 is  not  canceled completes as if the
       close() operation had not yet occurred. All  operations	that  are  not
       canceled	 shall complete as if the close() blocked until the operations
       completed. The close() operation itself need not	 block	awaiting  such
       I/O  completion.	 Whether  any I/O operation is canceled, and which I/O
       operation may be canceled upon close(), is implementation-defined.

       If a memory mapped file or a shared memory object remains referenced at
       the last close (that is, a process has it mapped), then the entire con‐
       tents of the memory  object  shall  persist  until  the	memory	object
       becomes	unreferenced.	If  this  is the last close of a memory mapped
       file or a shared memory object and the  close  results  in  the	memory
       object  becoming unreferenced, and the memory object has been unlinked,
       then the memory object shall be removed.

       If fildes refers to a socket, close() shall  cause  the	socket	to  be
       destroyed.  If  the  socket  is	in  connection-mode, and the SO_LINGER
       option is set for the socket with non-zero linger time, and the	socket
       has  untransmitted data, then close() shall block for up to the current
       linger interval until all data is transmitted.

       Upon successful completion, 0 shall be returned; otherwise, −1 shall be
       returned and errno set to indicate the error.

       The close() function shall fail if:

       EBADF  The fildes argument is not a open file descriptor.

       EINTR  The close() function was interrupted by a signal.

       The close() function may fail if:

       EIO    An  I/O error occurred while reading from or writing to the file

       The following sections are informative.

   Reassigning a File Descriptor
       The following example closes the file descriptor associated with	 stan‐
       dard  output  for  the current process, re-assigns standard output to a
       new file descriptor, and closes the original file descriptor  to	 clean
       up.  This  example  assumes  that  the  file descriptor 0 (which is the
       descriptor for standard input) is not closed.

	   #include <unistd.h>
	   int pfd;

       Incidentally, this is exactly what could be achieved using:

	   dup2(pfd, 1);

   Closing a File Descriptor
       In the following example, close() is used to close  a  file  descriptor
       after an unsuccessful attempt is made to associate that file descriptor
       with a stream.

	   #include <stdio.h>
	   #include <unistd.h>
	   #include <stdlib.h>

	   #define LOCKFILE "/etc/ptmp"
	   int pfd;
	   FILE *fpfd;
	   if ((fpfd = fdopen (pfd, "w")) == NULL) {

       An application that had used the stdio routine fopen() to open  a  file
       should  use  the	 corresponding	fclose()  routine rather than close().
       Once a file is closed, the file descriptor no longer exists, since  the
       integer corresponding to it no longer refers to a file.

       Implementations	may  use  file descriptors that must be inherited into
       child processes for the child process to remain conforming, such as for
       message	catalog	 or  tracing  purposes. Therefore, an application that
       calls close() on an arbitrary integer  risks  non-conforming  behavior,
       and  close()  can  only portably be used on file descriptor values that
       the application has obtained through explicit actions, as well  as  the
       three  file  descriptors corresponding to the standard file streams. In
       multi-threaded parent applications, the practice of calling close()  in
       a  loop	after  fork() and before an exec call in order to avoid a race
       condition of  leaking  an  unintended  file  descriptor	into  a	 child
       process,	 is therefore unsafe, and the race should instead be combatted
       by opening all file descriptors with the FD_CLOEXEC bit set unless  the
       file descriptor is intended to be inherited across exec.

       The use of interruptible device close routines should be discouraged to
       avoid problems with the implicit closes of file descriptors by exec and
       exit().	This volume of POSIX.1‐2008 only intends to permit such behav‐
       ior by specifying the [EINTR] error condition.

       Note that the requirement for close() on a socket to block  for	up  to
       the  current  linger interval is not conditional on the O_NONBLOCK set‐

       The standard developers rejected a proposal to add closefrom()  to  the
       standard. Because the standard permits implementations to use inherited
       file descriptors as a means of providing a conforming  environment  for
       the  child process, it is not possible to standardize an interface that
       closes arbitrary file descriptors above a  certain  value  while	 still
       guaranteeing a conforming environment.


       Section	2.6,  STREAMS,	exec, fattach(), fclose(), fdetach(), fopen(),
       ioctl(), open(), unlink()

       The Base Definitions volume of POSIX.1‐2008, <unistd.h>

       Portions of this text are reprinted and reproduced in  electronic  form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX),	The  Open  Group  Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
       cal and Electronics Engineers,  Inc  and	 The  Open  Group.   (This  is
       POSIX.1-2008  with  the	2013  Technical Corrigendum 1 applied.) In the
       event of any discrepancy between this version and the original IEEE and
       The  Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be  obtained	online
       at .

       Any  typographical  or  formatting  errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files  to  man page format. To report such errors, see https://www.ker‐ .

IEEE/The Open Group		     2013			     CLOSE(3P)

List of man pages available for Archlinux

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net