danburkert / procinfo-rs Goto Github PK

A Rust library for accessing Linux process and system information

License: Apache License 2.0

Rust 100.00%

procinfo-rs's Introduction

procinfo

A Rust library for reading information from /proc, the Linux process information psuedo-filesystem. procinfo provides a simple interface for inspecting process and system information on Linux.

Status

The goal is that procinfo will provide interfaces for all of the files in /proc, currently the following interfaces are provided:

/proc/loadavg
/proc/<pid>/cwd
/proc/<pid>/limits
/proc/<pid>/mountinfo
/proc/<pid>/stat
/proc/<pid>/statm
/proc/<pid>/status
/proc/sys/fs/file-max
/proc/net/dev

procinfo requires Rust 1.13 or later.

Contributing

Contributions will be gladly accepted for new /proc file parsers. In addition to parsers, help is needed testing procinfo on uncommon, old, bleeding edge, containerized, and namespaced kernels. If you find that any of the documentation is misleading, incomplete, or insufficient, please file an issue!

License

procinfo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE, LICENSE-MIT for details.

procinfo-rs's People

Contributors

Stargazers

Watchers

procinfo-rs's Issues

Other procfs-related projects

I stumbled upon this project from sozu-proxy/sozu#516, and I realized I've written a few things that might fit in:

https://bitbucket.org/marshallpierce/vm-info/src/master/, for inspecting virtual memory layout
https://bitbucket.org/marshallpierce/rpi-info/src/master/, for figuring out what kind of raspberry pi hardware is in use

To be clear, I'm happy to keep the projects separate if they're not a good fit, but if it looks like they would slot in nicely, it seems good to have One Procfs Project to Rule Them All so that users have one place to go. Anyway, let me know what you think. Warning: I have little time for OSS work at this very moment so if we choose to move forward, it'll be some time before I can attend to any needed modifications.

rustc overflows its stack on stable

Happens with both debug and release builds from current master (b0c8124).

$ cargo --version
cargo 0.13.0-nightly (109cb7c 2016-08-19)
$ rustc --version
rustc 1.12.0 (3191fbae9 2016-09-23)
$ git rev-parse HEAD
b0c8124920aab0bd17ca152d6520622e842cb953
$ cargo build --verbose
       Fresh byteorder v0.5.3
       Fresh nom v1.2.4
       Fresh libc v0.2.17
   Compiling procinfo v0.2.3 (file:///home/kamal/clones/procinfo-rs)
     Running `rustc src/lib.rs --crate-name procinfo --crate-type lib -g -C metadata=7bf4a2f3818aacc3 --out-dir /home/kamal/clones/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/home/kamal/clones/procinfo-rs/target/debug/deps --extern byteorder=/home/kamal/clones/procinfo-rs/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib --extern libc=/home/kamal/clones/procinfo-rs/target/debug/deps/liblibc-ad32fde1bd850538.rlib --extern nom=/home/kamal/clones/procinfo-rs/target/debug/deps/libnom-24d7a34b1cbfee73.rlib`

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: Could not compile `procinfo`.

Caused by:
  Process didn't exit successfully: `rustc src/lib.rs --crate-name procinfo --crate-type lib -g -C metadata=7bf4a2f3818aacc3 --out-dir /home/kamal/clones/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/home/kamal/clones/procinfo-rs/target/debug/deps --extern byteorder=/home/kamal/clones/procinfo-rs/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib --extern libc=/home/kamal/clones/procinfo-rs/target/debug/deps/liblibc-ad32fde1bd850538.rlib --extern nom=/home/kamal/clones/procinfo-rs/target/debug/deps/libnom-24d7a34b1cbfee73.rlib` (exit code: 1)

Why don't impl Debug trait to struct DeviceStatus?

Is there the reason not to impl Debug to DeviceStatus?
I added #[derive(Debug, PartialEq, Eq, Hash)] to DeviceStatus like Mountinfo, and didn't see any errors.

sysinfo

Hi !

I wrote a library (I use it in my process-viewer) which does similar things. Maybe it could be nice to merge our work or join our efforts, no ?

Why loadavg is 10 minutes

Just checking why you've named load average struct with 10 min, as it looks like 1, 5 and 15 mins values according to man proc. Are there any other post processing happening to convert it into 10 mins - though I couldn't see when skimming through source code?

rustc stack overflow on compilation

I'm getting thread 'rustc' has overflowed its stack when I compile. I've tried 0.2.2, 0.2.3 from crates.io and master from this repo and all have the same problem.

I've managed to compile all other crates in my project with the same setup without any issue.

$ rustc --version
rustc 1.12.0-nightly (080e0e072 2016-08-08)

$ cargo --version
cargo 0.13.0-nightly (6056c7d 2016-08-08)

I've installed with rustup. Let me know if there is any other information that I provide.

status fails with ""unable to parse whole input, remaining: Ok(...)"

Hello,

status(pid) fails in

Linux neil-laptop 4.4.0-45-generic #66~14.04.1-Ubuntu SMP Wed Oct 19 15:05:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I found a similar issue #8 , but the error is a little bit different.

Err(Error { repr: Custom(Custom { kind: InvalidInput, error: StringError("unable to parse whole input, remaining: Ok(\"VmPeak:\\t10927688 kB\\nVmSize:\\t10881308 kB\\nVmLck:\\t       0 kB\\nVmPin:\\t       0 kB\\nVmHWM:\\t   53924 kB\\nVmRSS:\\t     816 kB\\nVmData:\\t  372792 kB\\nVmStk:\\t     136 kB\\nVmExe:\\t    8880 kB\\nVmLib:\\t    2008 kB\\nVmPTE:\\t     208 kB\\nVmPMD:\\t      24 kB\\nVmSwap:\\t   24128 kB\\nHugetlbPages:\\t       0 kB\\nThreads:\\t11\\nSigQ:\\t0/31457\\nSigPnd:\\t0000000000000000\\nShdPnd:\\t0000000000000000\\nSigBlk:\\t0000000000000000\\nSigIgn:\\t0000000000000000\\nSigCgt:\\tffffffffffc1feff\\nCapInh:\\t0000000000000000\\nCapPrm:\\t0000000000000000\\nCapEff:\\t0000000000000000\\nCapBnd:\\t0000003fffffffff\\nCapAmb:\\t0000000000000000\\nSeccomp:\\t0\\nCpus_allowed:\\tf\\nCpus_allowed_list:\\t0-3\\nMems_allowed:\\t00000000,00000001\\nMems_allowed_list:\\t0\\nvoluntary_ctxt_switches:\\t600\\nnonvoluntary_ctxt_switches:\\t20\\n\")") }) })

Sample:

main.rs:

extern crate procinfo;

fn test_proc_status() {
    let status = procinfo::pid::status(32332);
    println!("{:?}", status);
}

fn main() {
    test_proc_status();
}

Cargo.toml:

[dependencies]
procinfo = "0.2.3"

status of 323332:

Name:	pd-server
State:	T (stopped)
Tgid:	32332
Ngid:	0
Pid:	32332
PPid:	7766
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
FDSize:	64
Groups:	4 24 27 30 46 108 124 126 999 1000 
NStgid:	32332
NSpid:	32332
NSpgid:	32332
NSsid:	7766
VmPeak:	10927688 kB
VmSize:	10881308 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	   53924 kB
VmRSS:	     816 kB
VmData:	  372792 kB
VmStk:	     136 kB
VmExe:	    8880 kB
VmLib:	    2008 kB
VmPTE:	     208 kB
VmPMD:	      24 kB
VmSwap:	   24128 kB
HugetlbPages:	       0 kB
Threads:	11
SigQ:	0/31457
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000000
SigCgt:	ffffffffffc1feff
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
Seccomp:	0
Cpus_allowed:	f
Cpus_allowed_list:	0-3
Mems_allowed:	00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	600
nonvoluntary_ctxt_switches:	20

Any ideas? Thanks!

Ability to change the proc pseudo fs path

I would find it very useful if the /proc path could be configured via env var. That's important for scenarios where the binary might be running inside container, but still wanting to read the host proc fs.

Is this crate dead?

It's been unusable since kernel 4.17 and there hasn't been much developer activity for a while...

nom 4.x

I would appreciate if you would upgrade nom dependency to 4.x

Crate does not compile on MacOS

I specify procinfo in my dev-dependencies because I have a Linux specific memory leak test, see https://github.com/klausi/rustnish/blob/goal-07/tests/memory_leaks.rs

On MacOS I simply skip that test. When compiling my project for cargo test the build fails because procinfo does not compile on MacOS.

Can we make procinfo compile on MacOS although we know it does not work there?

Doesn't compile on nightly, unable to figure out why

Hi!

I'm working on a project that I want to use procinfo in, but when I try to compile it on Rust nightly, is silently fails.

mk@maero /tmp/procinfo-rs % cargo build --verbose      
   Compiling nom v1.2.4
   Compiling libc v0.2.16
   Compiling byteorder v0.5.3
     Running `rustc /home/mk/.cargo/registry/src/github.com-1ecc6299db9ec823/nom-1.2.4/src/lib.rs --crate-name nom --crate-type lib -g --cfg feature=\"stream\" --cfg feature=\"default\" -C metadata=24d7a34b1cbfee73 -C extra-filename=-24d7a34b1cbfee73 --out-dir /tmp/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/tmp/procinfo-rs/target/debug/deps --cap-lints allow`
     Running `rustc /home/mk/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.16/src/lib.rs --crate-name libc --crate-type lib -g --cfg feature=\"use_std\" --cfg feature=\"default\" -C metadata=1417726cb94dbc83 -C extra-filename=-1417726cb94dbc83 --out-dir /tmp/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/tmp/procinfo-rs/target/debug/deps --cap-lints allow`
     Running `rustc /home/mk/.cargo/registry/src/github.com-1ecc6299db9ec823/byteorder-0.5.3/src/lib.rs --crate-name byteorder --crate-type lib -g --cfg feature=\"std\" --cfg feature=\"default\" -C metadata=e4fc6ea0c49cabcf -C extra-filename=-e4fc6ea0c49cabcf --out-dir /tmp/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/tmp/procinfo-rs/target/debug/deps --cap-lints allow`
   Compiling procinfo v0.2.3 (file:///tmp/procinfo-rs)
     Running `rustc src/lib.rs --crate-name procinfo --crate-type lib -g -C metadata=2d7d2b38dbaf2fdc --out-dir /tmp/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/tmp/procinfo-rs/target/debug/deps --extern nom=/tmp/procinfo-rs/target/debug/deps/libnom-24d7a34b1cbfee73.rlib --extern libc=/tmp/procinfo-rs/target/debug/deps/liblibc-1417726cb94dbc83.rlib --extern byteorder=/tmp/procinfo-rs/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib`
error: Could not compile `procinfo`.

Trying to run the rustc command with -v (for verbose information) yields no new information either.

mk@maero /tmp/procinfo-rs % rustc -v src/lib.rs --crate-name procinfo --crate-type lib -g -C metadata=2d7d2b38dbaf2fdc --out-dir /tmp/procinfo-rs/target/debug/deps --emit=dep-info,link -L dependency=/tmp/procinfo-rs/target/debug/deps --extern nom=/tmp/procinfo-rs/target/debug/deps/libnom-24d7a34b1cbfee73.rlib --extern libc=/tmp/procinfo-rs/target/debug/deps/liblibc-1417726cb94dbc83.rlib --extern byteorder=/tmp/procinfo-rs/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib 
rustc -v src/lib.rs --crate-name procinfo --crate-type lib -g -C  --out-dir    4,46s user 0,27s system 99% cpu 4,771 total

Do you have any ideas what could be causing it? Compiling with Rust stable works fine.

Get resource limits using getrlimit(2) / prlimit(2)

http://man7.org/linux/man-pages/man2/prlimit.2.html

status fails with "unable to parse whole input" for some processes on linux 4.4.8-hardened-r1

Hello,
pid::status fails with
Error { repr: Custom(Custom { kind: InvalidInput, error: StringError("unable to parse whole input") }) }
on approximately half the processes on my system (as an unprivileged user). The kernel version is 4.4.8-hardened-r1.
A sample failing /proc/.../status file :

Name:   zsh
State:  S (sleeping)
Tgid:   28892
Ngid:   0
Pid:    28892
PPid:   26857
TracerPid:  0
Uid:    0   0   0   0
Gid:    0   0   0   0
FDSize: 64
Groups: 0 1 2 3 4 6 10 11 26 27 
NStgid: 28892
NSpid:  28892
NSpgid: 28892
NSsid:  28892
VmPeak:    29852 kB
VmSize:    29628 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      4824 kB
VmRSS:      4616 kB
VmData:      676 kB
VmStk:       132 kB
VmExe:       684 kB
VmLib:      3824 kB
VmPTE:        76 kB
VmPMD:        12 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
Threads:    1
SigQ:   0/15419
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000384004
SigCgt: 0000000008013003
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp:    0
Cpus_allowed:   ffff
Cpus_allowed_list:  0-15
Mems_allowed:   00000000,00000001
Mems_allowed_list:  0
voluntary_ctxt_switches:    602
nonvoluntary_ctxt_switches: 7

Hope it helps

cannot parse /proc/pid/status on Linux 4.17.19

Error:

Err(Custom { kind: InvalidInput, error: StringError("unable to parse whole input, remaining: Ok(\"CoreDumping:\\t0\\nThreads:\\t1\\nSigQ:\\t0/31394\\nSigPnd:\\t0000000000000000\\nShdPnd:\\t0000000000000000\\nSigBlk:\\t0000000000000000\\nSigIgn:\\t0000000000004006\\nSigCgt:\\t0000000180000000\\nCapInh:\\t0000000000000000\\nCapPrm:\\t0000003fffffffff\\nCapEff:\\t0000003fffffffff\\nCapBnd:\\t0000003fffffffff\\nCapAmb:\\t0000000000000000\\nNoNewPrivs:\\t0\\nSeccomp:\\t0\\nSpeculation_Store_Bypass:\\tthread vulnerable\\nCpus_allowed:\\tff\\nCpus_allowed_list:\\t0-7\\nMems_allowed:\\t00000000,00000001\\nMems_allowed_list:\\t0\\nvoluntary_ctxt_switches:\\t3\\nnonvoluntary_ctxt_switches:\\t0\\n\")") })

corresponding /proc/pid/status

Name:	cat
Umask:	0022
State:	S (sleeping)
Tgid:	17417
Ngid:	0
Pid:	17417
PPid:	2011
TracerPid:	0
Uid:	0	0	0	0
Gid:	0	0	0	0
FDSize:	64
Groups:	0 
NStgid:	17417
NSpid:	17417
NSpgid:	2011
NSsid:	2011
VmPeak:	   16016 kB
VmSize:	   16016 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	     440 kB
VmRSS:	     440 kB
RssAnon:	      80 kB
RssFile:	     360 kB
RssShmem:	       0 kB
VmData:	     440 kB
VmStk:	     136 kB
VmExe:	    1428 kB
VmLib:	    2036 kB
VmPTE:	      68 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
Threads:	1
SigQ:	0/31394
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000004006
SigCgt:	0000000180000000
CapInh:	0000000000000000
CapPrm:	0000003fffffffff
CapEff:	0000003fffffffff
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
NoNewPrivs:	0
Seccomp:	0
Speculation_Store_Bypass:	thread vulnerable
Cpus_allowed:	ff
Cpus_allowed_list:	0-7
Mems_allowed:	00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	3
nonvoluntary_ctxt_switches:	0

System: 4.17.19

Publish on crates.io under name other than "proc"

It seems that due to "proc" still being a reserved keyword in rust, extern crate proc; doesn't work at all. Having the "proc" name saved for when rust doesn't have this restriction would be nice, but it'd probably be a good idea to publish under a different (usable) name as well.

status() returns Err: unable to parse whole input

I've run into this error in one of my own projects. Downloading the repo and running cargo test results in test pid::status::tests::test_status failing with the result:

thread 'pid::status::tests::test_status' panicked at 'called 'Result::unwrap()' on an Err value: Error { repr: Custom(Custom { kind: InvalidInput, error: StringError("unable to parse whole input, remaining: Ok(\"NoNewPrivs:\\t0\\nSeccomp:\\t0\\nCpus_allowed:\\tff\\nCpus_allowed_list:\\t0-7\\nMems_allowed:\\t00000000,00000001\\nMems_allowed_list:\\t0\\nvoluntary_ctxt_switches:\\t32\\nnonvoluntary_ctxt_switches:\\t7\\n\")") }) }', /checkout/src/libcore/result.rs:859

$cargo -V: 
cargo 0.18.0 (fe7b0cdcf 2017-04-24)
$rustc -V
rustc 1.17.0 (56124baa9 2017-04-24)

Doesn't build on Mac OSX

I am not sure why this is trying to build on Darwin?

[target.'cfg(unix)'.dependencies]
procinfo = "0.4"

error[E0308]: mismatched types
   --> /Users/dweaver/.cargo/registry/src/github.com-1ecc6299db9ec823/procinfo-0.4.2/src/pid/status.rs:189:1
    |
189 | named!(parse_umask<mode_t>,     delimited!(tag!("Umask:\t"),     parse_u32_octal,    line_ending));
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u16, found u32
    |
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
help: you can convert an `u32` to `u16` and panic if the converted value wouldn't fit
    |
9   |          { $ crate :: IResult :: Done (i1, o.try_into().unwrap()) }
    |                                            ^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error