12 releases

0.5.1 Oct 26, 2021
0.5.0 Jan 15, 2021
0.4.0 Oct 20, 2020
0.3.1 Jul 20, 2020
0.1.1 Oct 18, 2018

#864 in Unix APIs

Download history 10/week @ 2023-11-03 20/week @ 2023-11-10 7/week @ 2023-11-17 29/week @ 2023-11-24 40/week @ 2023-12-01 4/week @ 2023-12-08 20/week @ 2023-12-15 31/week @ 2023-12-22 2/week @ 2023-12-29 16/week @ 2024-01-05 4/week @ 2024-01-12 17/week @ 2024-01-19 15/week @ 2024-01-26 16/week @ 2024-02-02 19/week @ 2024-02-09 118/week @ 2024-02-16

168 downloads per month
Used in spirit

Apache-2.0 OR MIT

3.5K SLoC


Travis Build Status

Helpers and configuration fragments to integrate daemonization into the spirit configuration framework.

See the docs and the examples.


Licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.


A spirit extension for daemonization.

The configuration in here extends the spirit configuration framework to automatically go into background based on user's configuration and command line options.


use serde::Deserialize;
use spirit::Spirit;
use spirit::prelude::*;
use spirit_daemonize::{Daemon, Opts as DaemonOpts};
use structopt::StructOpt;

// From config files
#[derive(Default, Deserialize)]
struct Cfg {
    daemon: Daemon,

// From command line
#[derive(Debug, StructOpt)]
struct Opts {
    daemon: DaemonOpts,

fn main() {
     Spirit::<Opts, Cfg>::new()
        .with(unsafe {
            spirit_daemonize::extension(|c: &Cfg, o: &Opts| {
                (c.daemon.clone(), o.daemon.clone())
        .run(|_spirit| {
            // Possibly daemonized program goes here

Added options

The program above gets the -d command line option, which enables daemonization. Furthermore, the configuration now understands a new daemon section, with these options:

  • user: The user to become. Either a numeric ID or name. If not present, it doesn't change the user.
  • group: Similar as user, but with group.
  • pid-file: A pid file to write on startup. If not present, nothing is stored.
  • workdir: A working directory it'll switch into. If not set, defaults to /.
  • daemonize: Should this go into background or not? If combined with the Opts, it can be overridden on command line.

Multithreaded applications

As daemonization is done by using fork, you should start any threads after you initialize the spirit. Otherwise you'll lose the threads (and further bad things will happen).

The daemonization happens inside the application of validator actions of config_validator callback. If other config validators need to start any threads, they should be plugged in after the daemonization callback. However, the safer option is to start them inside the run method.


~107K SLoC