Spirit-daemonize

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

See the docs and the examples.

License

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

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.

lib.rs:

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.

Examples

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 {
    #[serde(default)]
    daemon: Daemon,
}

// From command line
#[derive(Debug, StructOpt)]
struct Opts {
    #[structopt(flatten)]
    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
            Ok(())
        });
}

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.