Unix signal handling

Unix signals are a mechanism for IPC which can be hard to handle correctly and safely. If you're implementing something like a Unix-like daemon, then handling Unix signals correctly may be quite important since daemons, by convention, take certain actions when they receive certain signals.

Unix (and maybe Windows)

The crates which are discussed in this section will work (or are intended to work) on Unix-likes and POSIX-compliant systems. They may also provide varying degrees of support for the Windows family of operating systems.

signal-hook

If you want to handle Unix signals, and only Unix signals, then signal-hook 0.3.17 is likely your best bet. It is well-documented and provides different mechanisms for handling signals, each of which is geared towards different kinds of applications. It is also the most downloaded crate on crates.io out of all the crates discussed on this page.

The following mechanisms are available in signal-hook 0.3.17 :

• Registering a function to be run when a signal is received. The register function is unsafe.
• Registering an Arc<AtomicBool> whose value is set to true when the signal is received.
• Registering an Arc<AtomicUsize whose value is set to a value, which you decide upon registration, when the signal is received.
• A pipe which has both ends in your application. When a signal is received, one byte (whose value is arbitrary) is written to the write end of the pipe.
• Iterators.
• Integration with mio 0.8.8 and tokio 1.25.2 (hidden behind feature flags).

General-purpose alternatives

These crates try to let you handle more than just SIGINT.

• asygnal 0.0.2 - Async signal-handling. Advertises support for CTRL + C signals, which likely means SIGINT.
• signal-simple 0.1.1 - Completely undocumented. No examples. Dependency of term-handler 0.1.0 .
• signalbool 0.2.5 - Set a flag when a signal is received. Uses an internal static AtomicUsize to store bitflags representing the set of signals which have been recieved. The library's SignalBool struct only stores a bitmask of the set of signals it handles. Compiles on Windows, but can only handle CTRL_C_EVENT and CTRL_BREAK_EVENT (disguised as SIGINT).

SIGINT/CTRL+C handlers

These crates are mostly interested in handling SIGINT.

• async-ctrlc 1.2.0 - Async wrapper around ctrlc 3.4.1 .
• ctrlc 3.4.1 - Handles SIGINT and optionally SIGTERM (through the "termination" feature). Handles CTRL_C_EVENT and CTRL_BREAK_EVENT on Windows. Has the most downloads on crates.io after signal-hook 0.3.17 .
• ctrlc_fnonce 0.1.0 - Tiny wrapper around ctrlc 3.4.1 which lets you provide a FnOnce closure which is called before process::exit is called.

Inactive crates

These are crates which have received no updates on crates.io for over a year.

• signal-notify 0.1.3 - Receive OS signals using mpsc::Receiver. Last updated on crates.io: 3 years ago.
• simple-signal 1.1.1 - Last updated on crates.io: 2 years ago.
• term-handler 0.1.0 - Block the thread while waiting SIGINT or SIGTERM. Last updated on crates.io: 2 years ago.

Deprecated crates

These are crates which will receive no further development and should not be used in new projects.

• chan-signal 0.3.3 - Respond to OS signals using chan 0.1.23 channels.

Windows only

The following crates technically don't do anything in regard to handling Unix signals, but they do offer functionality which is somewhat similar.

• wintrap 0.3.1 - Handle CTRL_C_EVENT, CTRL_BREAK_EVENT, CTRL_CLOSE_EVENT and WM_CLOSE.