sys-info-rs

A cross-platform Rust crate for reading CPU, memory, disk, load average, and OS release info via native system calls.

Library
Cargo
v0.9.1
172stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
37/100Needs Attention
Development Activity0
Maintenance0
Community68
Maturity60
Momentum20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
50/100Fair
Architecture55
Code Quality35
Innovation45
Learning Curve65

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.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search