package core

  1. Overview
  2. Docs
package core
Legend:
Library
Module
Module type
Parameter
Class
Class type

This module provides support for daemonizing a process. It provides flexibility as to where the standard file descriptors (stdin, stdout and stderr) are connected after daemonization has occurred.

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.

See Chapter 13 of Advanced Programming in the UNIX Environment Second Edition by Stephens and Rago for more details.

The optional arguments have defaults as per daemonize_wait, below.

By default, output sent to stdout and stderr after daemonization will be silently eaten. This behaviour may be adjusted by using redirect_stdout and redirect_stderr. See the documentation for daemonize_wait below.

See daemonize_wait for a description of allow_threads_to_have_been_created.

  • raises 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_kernel.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_stdout and redirect_stderr. The default is the usual behaviour whereby both of these descriptors are connected to /dev/null.

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 async, 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 release.

Forking, especially to daemonize, when running multiple threads is tricky, and generally a mistake. daemonize and daemonize_wait check that the current number of threads is not greater than expected. daemonize_wait and 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 shutdown. On non-Linux platforms, using ~allow_threads_to_have_been_created:true eliminates the protection daemonize and daemonize_wait have regarding threads.

  • raises Failure

    if fork was unsuccessful.

OCaml

Innovation. Community. Security.

GitHub Discord Twitter Peertube RSS
About
Changelog Releases Industrial Users Academic Users Why OCaml
Ecosystem
Packages Community Events OCaml Planet Jobs
Resources
Install OCaml Get Started Platform Tools Language Manual Standard Library API Books Exercises Papers OCaml Playground Logo
Policies
Carbon Footprint Governance Privacy Code of Conduct