sys-info-rs
A cross-platform Rust crate for reading CPU, memory, disk, load average, and OS release info via native system calls.
Repository Health
Technical Analysis
sys-info is a Rust crate for reading basic system information — CPU count and speed, memory and swap usage, disk space, load average, process count, hostname, boot time, and OS release — through a single cross-platform API. Under the hood it dispatches to small C shims per target OS (Linux, macOS, iOS, FreeBSD, OpenBSD, NetBSD, Solaris/illumos, Haiku, Windows), compiled automatically by its build.rs, so callers write one Rust API instead of per-platform FFI.
It has shipped since 2015, reached 172 GitHub stars and over 35 million cumulative crates.io downloads, and is MIT licensed with no restrictions. Development has slowed since its 0.9.1 release in October 2021 (no commits since May 2024), so teams evaluating it for new projects should weigh that against more actively maintained alternatives like the sysinfo crate.
What You Get
- A unified MemInfo/DiskInfo/LoadAvg struct API that reads the same way regardless of host OS
- Prebuilt C shims for Linux, macOS/iOS, FreeBSD, OpenBSD, NetBSD, Solaris/illumos, Haiku, and Windows, compiled automatically by build.rs
- A dedicated linux_os_release() parser for /etc/os-release fields (ID, NAME, VERSION_ID, PRETTY_NAME, and more)
- Result<T, Error>-wrapped calls so platform failures surface as errors instead of silent zeros
Common Use Cases
- Building lightweight host-metrics collectors for monitoring agents
- Printing a cross-platform system summary in a Rust CLI tool
- Gating memory- or disk-heavy background jobs on available resources
- Detecting the Linux distribution at install/setup time
Under The Hood
Architecture sys-info-rs is architected as a thin, single-layer FFI shim rather than a layered library: lib.rs exposes a flat set of free functions (os_type, os_release, linux_os_release, cpu_num, cpu_speed, loadavg, proc_total, mem_info, disk_info, hostname, boottime) that dispatch entirely through #[cfg(target_os = …)] conditional compilation into per-platform C sources under c/ (linux.c, darwin.c, freebsd.c, openbsd.c, netbsd.c, windows.c, haiku.c) plus a dedicated kstat.rs module for Solaris/illumos, with build.rs selecting and compiling the matching .c file via the cc crate at build time. There is no internal abstraction boundary beyond this dispatch: every public struct (LoadAvg, MemInfo, DiskInfo, LinuxOSReleaseInfo) is a plain #[repr(C)] value type shared verbatim across all platform branches, so changing a struct’s shape or adding a field ripples into every C shim and every cfg arm at once rather than being isolated behind an interface.
Tech Stack The crate’s only runtime dependency is libc for FFI bindings (sysctl, gethostname, timeval, and similar), with cc pulled in solely as a build-dependency to compile the bundled C sources through build.rs; there’s no async runtime, database, or web framework anywhere in the stack since the crate’s entire job is exposing OS-level syscalls and /proc or sysctl reads to Rust callers. Distribution is purely as a Cargo library meant to be vendored into other binaries, and its platform coverage — Linux, macOS/iOS, FreeBSD, OpenBSD, NetBSD, Solaris/illumos, Haiku, and Windows — is each handled with its own compiled C shim selected by build.rs’s target-triple matching.
Code Quality There is no real automated test suite: the only artifact under test/ is a standalone demo binary (test/src/main.rs) that calls each public function and prints the result with .unwrap(), with zero #[test] functions or assertions, and CI is limited to a now-defunct Travis badge in the README. Error handling is consistent, though — nearly every public function returns a Result using a shared custom Error type, so callers are forced to handle platform failures explicitly rather than the crate silently returning zeroed structs. Naming is idiomatic snake_case throughout and public types carry doc comments, but there’s no linter or formatter configuration checked in, and no evidence the C shims are exercised by anything beyond manual testing.
API Design The public API favors minimal ceremony over expressiveness: each metric is a single free-function call (sys_info::mem_info().unwrap(), sys_info::cpu_num().unwrap()) returning a small plain struct, with no builder pattern, no configuration object, and almost no boilerplate to get a first reading. That simplicity is also its ceiling — this is a straightforward wrapper around long-standing OS interfaces (sysctl, /proc, GetSystemInfo) rather than a novel measurement technique, and the ecosystem has since produced more actively maintained alternatives covering similar ground with broader platform parity and ongoing releases; sys-info-rs itself has had no commits since May 2024.