daemon(3) [mojave man page]

DAEMON(3)						   BSD Library Functions Manual 						 DAEMON(3)

NAME

     daemon -- run in the background

LIBRARY

     Standard C Library (libc, -lc)

SYNOPSIS

     #include <stdlib.h>

     int
     daemon(int nochdir, int noclose);

DESCRIPTION

     The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons.
     The fork(2) system call is used; see CAVEATS below about the environment after a fork() (without a corresponding call to one of the exec rou-
     tines).  On Mac OS X, the use of this API is discouraged in favor of using launchd(8).

     Unless the argument nochdir is non-zero, daemon() changes the current working directory to the root (/).

     Unless the argument noclose is non-zero, daemon() will redirect standard input, standard output, and standard error to /dev/null.

RETURN VALUES

     The daemon() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate
     the error.

ERRORS

     The daemon() function may fail and set errno for any of the errors specified for the library functions fork(2) and setsid(2).

SEE ALSO

     fork(2), launchd(8), setsid(2), sigaction(2)

HISTORY

     The daemon() function first appeared in 4.4BSD.

CAVEATS

     There are limits to what you can do in the child process.	To be totally safe you should restrict yourself to only executing async-signal
     safe operations (see sigaction(2)) until such time as one of the exec functions is called.  All APIs, including global data symbols, in any
     framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe.  If you need
     to use these frameworks in the child process, you must exec.  In this situation it is reasonable to exec yourself.

     Unless the noclose argument is non-zero, daemon() will close the first three file descriptors and redirect them to /dev/null.  Normally,
     these correspond to standard input, standard output, and standard error.  However, if any of those file descriptors refer to something else,
     they will still be closed, resulting in incorrect behavior of the calling program.  This can happen if any of standard input, standard out-
     put, or standard error have been closed before the program was run.  Programs using daemon() should therefore either call daemon() before
     opening any files or sockets, or verify that any file descriptors obtained have values greater than 2.

     The daemon() function temporarily ignores SIGHUP while calling setsid(2) to prevent a parent session group leader's calls to fork(2) and then
     _exit(2) from prematurely terminating the child process.

BSD
								   June 9, 1993 							       BSD

Check Out this Related Man Page

PTHREAD_ATFORK(3)					   BSD Library Functions Manual 					 PTHREAD_ATFORK(3)

NAME

     pthread_atfork -- register handlers to be called when process forks

LIBRARY

     Standard C Library (libc, -lc)

SYNOPSIS

     #include <pthread.h>

     int
     pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void));

DESCRIPTION

     The pthread_atfork() function registers the provided handler functions to be called when the fork(2) function is called.  Each of the three
     handlers is called at a different place in the fork(2) sequence.  The prepare handler is called in the parent process before the fork hap-
     pens, the parent handler is called in the parent process after the fork has happened, and the child handler is called in the child process
     after the fork has happened.  The parent and child handlers are called in the order in which they were registered, while the prepare handlers
     are called in reverse of the order in which they were registered.

     Any of the handlers given may be NULL.

     The intended use of pthread_atfork() is to provide a consistent state to a child process from a multithreaded parent process where locks may
     be acquired and released asynchronously with respect to the fork(2) call.	Each subsystem with locks that are used in a child process should
     register handlers with pthread_atfork() that acquires those locks in the prepare handler and releases them in the parent handler.

RETURN VALUES

     The pthread_atfork() function returns 0 on success and an error number on failure.

ERRORS

     The following error code may be returned:

     [ENOMEM]		Insufficient memory exists to register the fork handlers.

SEE ALSO

     fork(2)

STANDARDS

     The pthread_atfork() function conforms to IEEE Std 1003.1c-1995 (``POSIX.1'').

HISTORY

     The pthread_atfork() function first appeared in NetBSD 2.0.

CAVEATS

     After calling fork(2) from a multithreaded process, it is only safe to call async-signal-safe functions until calling one of the exec(3)
     functions.  The pthread_*() functions are not async-signal-safe, so it is not safe to use such functions in the child handler.

BUGS

     There is no way to unregister a handler registered with pthread_atfork().

BSD
								 February 12, 2003							       BSD

Linux and UNIX Man Pages

daemon(3) [mojave man page]

Check Out this Related Man Page