sysinfo

Cross-platform Rust library for fetching system information — CPU, memory, disks, processes, and networks

Library
Cargo
v0.39.6
2,747 stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum. How we score it →
80 /100 Excellent
Development Activity 100
Maintenance 52
Community 68
Maturity 60
Momentum 40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation. How we score it →
76 /100 Good
Architecture 80
Code Quality 82
Innovation 72
Learning Curve 70

sysinfo is a Rust crate that provides a unified, cross-platform API for reading a machine’s live system information: CPU usage per core, total and used memory/swap, disk usage and I/O, network interface traffic, running processes (with per-process CPU, memory, and disk usage), hardware components and their temperatures, and user account listings. It supports Linux, macOS, Windows, FreeBSD, NetBSD, Android, iOS, and Raspberry Pi, gracefully returning empty values on unsupported platforms rather than failing to compile or run.

The crate is built around a long-lived System struct that must be refreshed (via refresh_all() or more targeted refresh_* methods) before reading up-to-date values, since many metrics (like CPU usage) are computed as a diff between successive reads. It also exposes a C-compatible interface for use from non-Rust codebases and is one of the most widely downloaded Rust crates for system monitoring, powering task managers, monitoring agents, and diagnostic tooling across the Rust ecosystem.

What You Get

  • A unified System struct exposing CPU, memory/swap, process, disk, network, and component (temperature) information across 8 supported OSes
  • Fine-grained refresh_specifics(...) methods to update only the metrics you need, avoiding the cost of a full refresh
  • Per-process details including CPU usage, memory usage, and disk I/O, keyed by PID
  • A C-compatible interface (c_interface.rs + sysinfo.h) for use from C or other FFI-capable languages
  • Graceful degradation on unsupported platforms — calls return empty values instead of failing to compile or panicking
  • Optional multithread feature for parallelized data collection on supported platforms

Common Use Cases

  • Building system monitoring dashboards or task-manager-style applications in Rust
  • Collecting host-level telemetry (CPU, memory, disk, network) for observability agents and exporters
  • Implementing resource-aware process managers or schedulers that need live CPU/memory usage per process
  • Cross-platform diagnostic and troubleshooting tools that need consistent system data across Linux, macOS, and Windows

Under The Hood

Architecture - sysinfo is architected around a common public API (lib.rs, common/) that dispatches to per-platform backend modules — unix/linux, unix/apple, unix/bsd, windows, and an unknown fallback — each implementing the same trait-like surface (System, Cpu, Disks, Networks, Components, Users) using that platform’s native syscalls or /proc//sys filesystem reads. This lets consumers write one code path (System::new_all(), sys.refresh_all()) that behaves consistently regardless of the underlying OS. Tech Stack - Pure Rust core with FFI (a c_interface.rs module and generated sysinfo.h) for C consumers; platform backends call directly into OS-specific APIs (Windows APIs on Windows, sysctl/IOKit on macOS, /proc and /sys on Linux) without going through heavier abstraction crates; an optional multithread feature parallelizes data collection at the cost of higher memory use on some platforms. Code Quality - The project maintains a dedicated tests/ directory with per-feature test files (cpu, disk, network, process, users, components) plus code_checkers tooling, and explicitly documents that tests should run with --test-threads=1 since system-level reads can interfere with each other in parallel; with 214 contributors and near-continuous commit activity, the crate shows an unusually mature maintenance process for a systems-level library. API Design - The API favors a long-lived, refreshable System instance over stateless calls (since metrics like CPU usage require a diff between two reads), and the README is explicit about this performance-sensitive usage pattern, plus offers refresh_specifics for consumers who only need a subset of data — a thoughtful ergonomic tradeoff for a library whose naive usage pattern could otherwise be a performance footgun.

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