The qsu ("kazoo") crate offers portable service utilities with an (opinionated) service wrapper runtime.

qsu's primary objective is to allow a service developer to focus on the actual service application code, without having to bother with service subsystem-specific integrations -- while at the same time allowing the service application to run as a regular foreground process, without the code needing to diverge between the two.

Features

• qsu offers two primary runtime types:
  • Sync is for "non-async" service applications.
  • Tokio is for tokio-based async service applications.
• In addition is offers special-purpose service runtimes for:
  • Rocket is an tokio/async runtime environment with helpers for Rocket applications.
• The runtime uses two logging systems; log and tracing -- it assumes that log is used for production logs, and tracing is used for developer logs.
• It offers an optional command line argument parser, based on clap, that provides a (configurable) command line interface for registering, running and deregistering the service.
• It provides an installation module that can register/deregister services on Windows, and generate system service unit files for systemd or launcher plist files for launchd.

Known limitations

• There are several assumptions made in qsu about paths being utf-8. Even if a public interface takes a Path or PathBuf, the function may return an error if the path isn't utf-8 compliant.

Further reading

• How to use the qsu runtime - This should be read by both both developers and administrators using a service written on top of qsu.
• See design notes for a high-level overview of how the qsu wrapper runtime is implemented.
• Examples:
  • The source repository contains several qsu examples.
  • The staticrocket crate uses qsu.

Feature labels in documentation

The crate's documentation uses automatically generated feature labels, which currently requires nightly featuers. To build the documentation locally use:

RUSTFLAGS="--cfg docsrs" RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --all-features

Change log

The details of changes can always be found in the timeline, but for a high-level view of changes between released versions there's a manually maintained Change Log.

Project status

This crate is a work-in-progress -- still in early prototyping stage. This means potentially significant API instability between versions and incomplete, or even incorrect, documentation.

It is recommended that projects wanting to use qsu at this point use the tests and examples for up-to-date information on how to use the crate.