EXIT man page on Scientific

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

EXIT(3P)		   POSIX Programmer's Manual		      EXIT(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.

       exit, _Exit, _exit - terminate a process

       #include <stdlib.h>

       void exit(int status);
       void _Exit(int status);

       #include <unistd.h>
       void _exit(int status);

       For exit() and _Exit():	 The functionality described on this reference
       page  is	 aligned  with	the  ISO C  standard. Any conflict between the
       requirements described here and the ISO C  standard  is	unintentional.
       This volume of IEEE Std 1003.1-2001 defers to the ISO C standard.

       The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE,  or any other
       value, though only the least significant 8  bits	 (that	is,  status  &
       0377) shall be available to a waiting parent process.

       The  exit()  function  shall  first  call  all  functions registered by
       atexit(), in the reverse order of their	registration,  except  that  a
       function	 is  called after any previously registered functions that had
       already been called at the time it was  registered.  Each  function  is
       called  as  many times as it was registered. If, during the call to any
       such function, a call to the longjmp() function is made that would ter‐
       minate the call to the registered function, the behavior is undefined.

       If  a  function	registered  by a call to atexit() fails to return, the
       remaining registered functions shall not be called and the rest of  the
       exit() processing shall not be completed. If exit() is called more than
       once, the behavior is undefined.

       The exit() function shall then flush all open  streams  with  unwritten
       buffered	 data, close all open streams, and remove all files created by
       tmpfile(). Finally, control shall be terminated with  the  consequences
       described below.

       The _Exit() and _exit() functions shall be functionally equivalent.

       The _Exit()  and _exit()	 functions shall not call functions registered
       with atexit() nor any registered signal handlers.  Whether open streams
       are  flushed  or	 closed, or temporary files are removed is implementa‐
       tion-defined. Finally, the calling process is terminated with the  con‐
       sequences described below.

       These functions shall terminate the calling process  with the following

       Note:  These consequences are all extensions to the ISO C standard  and
	      are not further CX shaded. However, XSI extensions are shaded.

	* All of the file descriptors, directory streams,  conversion descrip‐
	  tors, and message catalog descriptors open in	 the  calling  process
	  shall be closed.

	* If  the  parent process of the calling process is executing a wait()
	  or waitpid(),	 and has neither set its  SA_NOCLDWAIT	flag  nor  set
	  SIGCHLD  to  SIG_IGN,	  it shall be notified of the calling process'
	  termination and the low-order eight bits (that  is,  bits  0377)  of
	  status  shall be made available to it. If the parent is not waiting,
	  the child's status shall be made available to	 it  when  the	parent
	  subsequently executes wait() or waitpid().

       The semantics of the waitid() function shall be equivalent to wait().

	* If  the  parent  process  of	the calling process is not executing a
	  wait() or waitpid(),	and has neither set its SA_NOCLDWAIT flag  nor
	  set  SIGCHLD	to  SIG_IGN,  the calling process shall be transformed
	  into a zombie process. A zombie process is an inactive  process  and
	  it  shall be deleted at some later time when its parent process exe‐
	  cutes wait() or waitpid().

       The semantics of the waitid() function shall be equivalent to wait().

	* Termination of a process does not directly terminate	its  children.
	  The  sending of a SIGHUP signal as described below indirectly termi‐
	  nates children in some circumstances.

	* Either:

       If the implementation supports the SIGCHLD signal, a SIGCHLD  shall  be
       sent to the parent process.


       If  the parent process has set its SA_NOCLDWAIT flag, or set SIGCHLD to
       SIG_IGN, the status shall be discarded, and the lifetime of the calling
       process	shall end immediately. If SA_NOCLDWAIT is set, it is implemen‐
       tation-defined whether a SIGCHLD signal is sent to the parent process.

	* The parent process ID of all of the calling process' existing	 child
	  processes  and zombie processes shall be set to the process ID of an
	  implementation-defined system	 process.  That	 is,  these  processes
	  shall be inherited by a special system process.

	* Each	attached  shared-memory	 segment  is detached and the value of
	  shm_nattch (see shmget()) in the data structure associated with  its
	  shared memory ID shall be decremented by 1.

	* For  each  semaphore	for which the calling process has set a semadj
	  value (see semop()), that value shall be added to the semval of  the
	  specified semaphore.

	* If  the process is a controlling process, the SIGHUP signal shall be
	  sent to each process in the foreground process group of the control‐
	  ling terminal belonging to the calling process.

	* If  the  process  is a controlling process, the controlling terminal
	  associated with the session shall be disassociated from the session,
	  allowing it to be acquired by a new controlling process.

	* If  the  exit	 of  the  process  causes  a  process  group to become
	  orphaned, and if any member of the newly-orphaned process  group  is
	  stopped,  then a SIGHUP signal followed by a SIGCONT signal shall be
	  sent to each process in the newly-orphaned process group.

	* All open named semaphores in the calling process shall be closed  as
	  if by appropriate calls to sem_close().

	* Any  memory locks established by the process via calls to mlockall()
	  or mlock() shall be removed. If locked pages in the address space of
	  the calling process are also mapped into the address spaces of other
	  processes and are locked by those processes, the  locks  established
	  by  the  other  processes  shall  be	unaffected by the call by this
	  process to _Exit() or _exit().

	* Memory mappings that were created in the process shall  be  unmapped
	  before the process is destroyed.

	* Any  blocks  of typed memory that were mapped in the calling process
	  shall be unmapped, as if munmap() was	 implicitly  called  to	 unmap

	* All  open  message queue descriptors in the calling process shall be
	  closed as if by appropriate calls to mq_close().

	* Any outstanding cancelable asynchronous I/O operations may  be  can‐
	  celed.   Those  asynchronous	I/O  operations	 that are not canceled
	  shall complete as if the _Exit() or _exit() operation	 had  not  yet
	  occurred,  but  any  associated  signal  notifications shall be sup‐
	  pressed. The _Exit() or _exit() operation may	 block	awaiting  such
	  I/O  completion.  Whether  any I/O is canceled, and which I/O may be
	  canceled upon _Exit() or _exit(), is implementation-defined.

	* Threads terminated by a call to _Exit() or _exit() shall not	invoke
	  their cancellation cleanup handlers or per-thread data destructors.

	* If  the  calling  process  is	 a trace controller process, any trace
	  streams that were created by the calling process shall be shut  down
	  as   described  by  the  posix_trace_shutdown()  function,  and  any
	  process' mapping of trace event names to trace  event	 type  identi‐
	  fiers built for these trace streams may be deallocated.

       These functions do not return.

       No errors are defined.

       The following sections are informative.


       Normally applications should use exit() rather than _Exit() or _exit().

   Process Termination
       Early  proposals drew a distinction between normal and abnormal process
       termination. Abnormal termination was caused only  by  certain  signals
       and  resulted  in implementation-defined "actions", as discussed below.
       Subsequent proposals distinguished three types of  termination:	normal
       termination (as in the current specification), simple abnormal termina‐
       tion, and abnormal termination  with  actions.  Again  the  distinction
       between the two types of abnormal termination was that they were caused
       by different signals  and  that	implementation-defined	actions	 would
       result  in  the	latter	case. Given that these actions were completely
       implementation-defined, the early proposals were only saying  when  the
       actions could occur and how their occurrence could be detected, but not
       what they were. This was of little or no	 use  to  conforming  applica‐
       tions,  and  thus  the  distinction  is	not  made  in  this  volume of
       IEEE Std 1003.1-2001.

       The implementation-defined actions usually include, in most  historical
       implementations, the creation of a file named core in the current work‐
       ing directory of the process. This file contains an image of the memory
       of  the	process,  together  with  descriptive  information  about  the
       process, perhaps sufficient to reconstruct the state of the process  at
       the receipt of the signal.

       There  is  a  potential security problem in creating a core file if the
       process was set-user-ID and the current user is not the	owner  of  the
       program,	 if the process was set-group-ID and none of the user's groups
       match the group of the program, or if the user does not have permission
       to write in the current directory. In this situation, an implementation
       either should not create a core file or should make  it	unreadable  by
       the user.

       Despite the silence of this volume of IEEE Std 1003.1-2001 on this fea‐
       ture, applications are advised not to create files named	 core  because
       of  potential  conflicts in many implementations.  Some implementations
       use a name other than core for the file; for example, by appending  the
       process ID to the filename.

   Terminating a Process
       It  is  important  that	the  consequences  of  process	termination as
       described occur regardless of whether the process called _exit()	 (per‐
       haps indirectly through exit()) or instead was terminated due to a sig‐
       nal or for some other reason. Note that in the specific case of	exit()
       this  means  that  the status argument to exit() is treated in the same
       way as the status argument to _exit().

       A language other than C may have other termination primitives than  the
       C-language  exit()  function,  and  programs written in such a language
       should use its native termination primitives, but those should have  as
       part  of their function the behavior of _exit() as described. Implemen‐
       tations in languages other than C are outside the scope of this version
       of this volume of IEEE Std 1003.1-2001, however.

       As  required  by	 the  ISO C standard, using return from main() has the
       same behavior (other than with respect to  language  scope  issues)  as
       calling exit() with the returned value.	Reaching the end of the main()
       function has the same behavior as calling exit(0).

       A value of zero (or EXIT_SUCCESS, which is required to be zero) for the
       argument	 status	 conventionally indicates successful termination. This
       corresponds to the specification for exit() in the ISO C standard.  The
       convention  is  followed	 by utilities such as make and various shells,
       which interpret a zero status from a child process as success. For this
       reason, applications should not call exit(0) or _exit(0) when they ter‐
       minate unsuccessfully; for example, in signal-catching functions.

       Historically, the implementation-defined process that inherits children
       whose  parents  have  terminated without waiting on them is called init
       and has a process ID of 1.

       The sending of a SIGHUP to the foreground process group when a control‐
       ling  process  terminates  corresponds to somewhat different historical
       implementations. In System V, the kernel sends a SIGHUP on  termination
       of (essentially) a controlling process. In 4.2 BSD, the kernel does not
       send SIGHUP in a case like this, but the termination of	a  controlling
       process is usually noticed by a system daemon, which arranges to send a
       SIGHUP to the foreground process group  with  the  vhangup()  function.
       However, in 4.2 BSD, due to the behavior of the shells that support job
       control, the controlling process is usually a shell with no other  pro‐
       cesses in its process group. Thus, a change to make _exit() behave this
       way in such systems should not cause problems  with  existing  applica‐

       The  termination	 of  a	process	 may  cause  a process group to become
       orphaned in either of two ways. The connection of a  process  group  to
       its  parent(s)  outside	of  the	 group depends on both the parents and
       their children. Thus, a process group may be orphaned by	 the  termina‐
       tion  of	 the last connecting parent process outside of the group or by
       the  termination	 of  the  last	direct	descendant   of	  the	parent
       process(es).  In	 either case, if the termination of a process causes a
       process group to become orphaned, processes within the group  are  dis‐
       connected  from their job control shell, which no longer has any infor‐
       mation on the existence of the process group. Stopped processes	within
       the  group  would  languish  forever.   In order to avoid this problem,
       newly orphaned process groups that contain stopped processes are sent a
       SIGHUP signal and a SIGCONT signal to indicate that they have been dis‐
       connected from their session. The  SIGHUP  signal  causes  the  process
       group members to terminate unless they are catching or ignoring SIGHUP.
       Under most circumstances, all of the members of the process  group  are
       stopped if any of them are stopped.

       The  action  of	sending	 a SIGHUP and a SIGCONT signal to members of a
       newly orphaned process group is similar to the action of 4.2 BSD, which
       sends  SIGHUP  and SIGCONT to each stopped child of an exiting process.
       If such children exit in response to the SIGHUP, any additional descen‐
       dants  receive  similar	treatment  at  that  time.   In this volume of
       IEEE Std 1003.1-2001, the signals are sent to the entire process	 group
       at the same time. Also, in this volume of IEEE Std 1003.1-2001, but not
       in 4.2 BSD, stopped processes may be orphaned, but may be members of  a
       process	group  that  is	 not  orphaned; therefore, the action taken at
       _exit() must consider processes other than child processes.

       It is possible for a  process  group  to	 be  orphaned  by  a  call  to
       setpgid()  or  setsid(), as well as by process termination. This volume
       of IEEE Std 1003.1-2001 does not require sending SIGHUP and SIGCONT  in
       those  cases,  because, unlike process termination, those cases are not
       caused accidentally by applications that are unaware of job control. An
       implementation  can choose to send SIGHUP and SIGCONT in those cases as
       an extension; such an extension must be documented as required in <sig‐

       The  ISO/IEC 9899:1999  standard adds the _Exit() function that results
       in  immediate  program  termination  without  triggering	  signals   or
       atexit()-registered functions. In IEEE Std 1003.1-2001, this is equiva‐
       lent to the _exit() function.


       atexit(),   close(),   fclose(),	  longjmp(),   posix_trace_shutdown(),
       posix_trace_trid_eventid_open(), semop(), shmget(), sigaction(), wait()
       ,   waitid(),   waitpid(),   the	   Base	   Definitions	  volume    of
       IEEE Std 1003.1-2001, <stdlib.h>, <unistd.h>

       Portions	 of  this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       --  Portable  Operating	System	Interface (POSIX), The Open Group Base
       Specifications Issue 6, Copyright (C) 2001-2003	by  the	 Institute  of
       Electrical  and	Electronics  Engineers, Inc and The Open Group. 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 http://www.opengroup.org/unix/online.html .

IEEE/The Open Group		     2003			      EXIT(3P)

List of man pages available for Scientific

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