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)[edit | edit source]
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[edit | edit source]
If you want to handle Unix signals, and only Unix signals, then
signal-hook 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
- Registering a function to be run when a signal is received. The
registerfunction is unsafe.
- Registering an
Arc<AtomicBool>whose value is set to
truewhen the signal is received.
- Registering an
Arc<AtomicUsizewhose 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.
- Integration with
tokio(hidden behind feature flags).
General-purpose alternatives[edit | edit source]
These crates try to let you handle more than just SIGINT.
asygnal- Async signal-handling. Advertises support for
Csignals, which likely means SIGINT.
signal-simple- Completely undocumented. No examples. Dependency of
signalbool- Set a flag when a signal is received. Uses an internal static
to store bitflags representing the set of signals which have been recieved. The library's
SignalBoolstruct 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[edit | edit source]
These crates are mostly interested in handling SIGINT.
async-ctrlc- Async wrapper around
ctrlc- 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
ctrlc_fnonce- Tiny wrapper around
ctrlcwhich lets you provide a
FnOnceclosure which is called before
Inactive crates[edit | edit source]
These are crates which have received no updates on crates.io for over a year.
signal-notify- Receive OS signals using
. Last updated on crates.io: 3 years ago.
simple-signal- Last updated on crates.io: 2 years ago.
term-handler- Block the thread while waiting SIGINT or SIGTERM. Last updated on crates.io: 2 years ago.
Deprecated crates[edit | edit source]
These are crates which will receive no further development and should not be used in new projects.
Windows only[edit | edit source]
The following crates technically don't do anything in regard to handling Unix signals, but they do offer functionality which is somewhat similar.
wintrap- Handle CTRL_C_EVENT, CTRL_BREAK_EVENT, CTRL_CLOSE_EVENT and WM_CLOSE.