While here, fix missing comma typo.
MFC after: 3 days
Obtained from: https://github.com/apple-oss-distributions/libc (partially)
Sponsored by: Klara, Inc.
Differential D57384
daemon(3): Note about environment after calling daemon() Authored by obiwac on Mon, Jun 1, 4:26 PM. Tags None Referenced Files
Details While here, fix missing comma typo. MFC after: 3 days Rendered manpage: DAEMON(3) FreeBSD 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);
int
daemonfd(int chdirfd, int nullfd);
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 routines).
If the argument nochdir is zero, daemon() changes the current working
directory to the root (/).
If the argument noclose is zero, daemon() redirects standard input,
standard output, and standard error to /dev/null.
The daemonfd() function is equivalent to the daemon() function except that
arguments are the descriptors for the current working directory and to the
descriptor to /dev/null.
If chdirfd is equal to (-1) the current working directory is not changed.
If nullfd is equals to (-1) the redirection of standard input, standard
output, and standard error is not closed.
RETURN VALUES
The daemon() and daemonfd() functions return 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() and daemonfd() function may fail and set errno for any of the
errors specified for the library functions fork(2), open(2), and setsid(2).
SEE ALSO
fork(2), setsid(2), sigaction(2)
HISTORY
The daemon() function first appeared in 4.4BSD. The daemonfd() function
first appeared in FreeBSD 12.0.
CAVEATS
In multithreaded programs, the child process after fork() inherits copies
of all mutexes and other synchronization state, but only the calling thread
survives. Any locks held by other threads at the time of the call will
remain permanently acquired in the child, causing deadlocks in any library
that attempts to acquire them. Until one of the exec(3) functions is
called, the child should restrict itself to async-signal safe operations
(see sigaction(2)).
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 output, 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.
FreeBSD 16.0-CURRENT June 1, 2026 DAEMON(3)
Diff Detail
Event TimelineComment Actions We probably should revise the wording a bit, because I think the situation is a little different in FreeBSD. In a single-threaded program you're probably fine anyways and daemon(3) + operating normally without exec is a pretty common pattern here, but it's probably still worth pointing out that there are risks. It's harder to advise in Darwin because, iirc, you can't really safely even syslog(3) from the post-fork context since the underlying library uses Mach ports that are invalidated after a fork. Comment Actions That's fair. I didn't really know of the other reasons specific to darwin, but I guess I can at least reword this to explain the issue on FreeBSD for multithreaded programs. |