module Fd_redirection : sig ... end
val daemonize : ?redirect_stdout:Fd_redirection.t -> ?redirect_stderr:Fd_redirection.t -> ?cd:string -> ?umask:int -> ?allow_threads_to_have_been_created:bool -> unit -> unit
daemonize makes the executing process a daemon.
The optional arguments have defaults as per
By default, output sent to stdout and stderr after daemonization will be silently eaten. This behaviour may be adjusted by using
redirect_stderr. See the documentation for
daemonize_wait for a description of
Failure if fork was unsuccessful.
val daemonize_wait : ?redirect_stdout:Fd_redirection.t -> ?redirect_stderr:Fd_redirection.t -> ?cd:string -> ?umask:int -> ?allow_threads_to_have_been_created:bool -> unit -> ( unit -> unit ) Core.Staged.t
daemonize_wait makes the executing process a daemon, but delays full detachment from the calling shell/process until the returned "release" closure is called.
Any output to stdout/stderr before the "release" closure is called will get sent out normally. After "release" is called, stdin is connected to /dev/null, and stdout and stderr are connected as specified by
redirect_stderr. The default is the usual behavior whereby both of these descriptors are connected to /dev/null.
daemonize_wait, however, will not redirect stdout/stderr to /dev/null if they are already redirected to a regular file by default, i.e., default redirection is
`Dev_null_skip_regular_files. This is to preserve behavior from earlier versions.)
Note that calling
release will adjust SIGPIPE handling, so you should not rely on the delivery of this signal during this time.
daemonize_wait allows you to daemonize and then start asynchronously, but still have stdout/stderr go to the controlling terminal during startup. By default, when you
daemonize, toplevel exceptions during startup would get sent to /dev/null. With
daemonize_wait, toplevel exceptions can go to the terminal until you call
Forking (especially to daemonize) when running multiple threads is tricky and generally a mistake.
daemonize_wait check that the current number of threads is not greater than expected.
daemonize also check that threads have not been created, which is more conservative than the actual requirement that multiple threads are not running. Using
~allow_threads_to_have_been_created:true bypasses that check. This is useful if Async was previously running, and therefore threads have been created, but has since been shut down. On non-Linux platforms, using
~allow_threads_to_have_been_created:true eliminates the protection
daemonize_wait have regarding threads.
Failure if forking was unsuccessful.