danburkert/procinfo-rs

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

kamalmarhubi opened this issue · 7 comments

(I thought this was already implemented by parsing /proc/<pid>/limits but was confused with the Prometheus client library.)

rlimit and prlimit have bindings in the libc crate, so perhaps use those? I don't intend for this library to provide bindings for system/libc calls, although I do think it's appropriate to have a parser for /proc/<pid>/limits. Another way of putting it: procinfo has a parser for /proc/<pid>/cwd even though everyone should prefer using std::env::current_dir.

Yeah, I would do it with those. If you think a parser is better, that's also something that I could do.

I think a parser is in scope for this crate, so I would definitely accept a
PR. That being said, if I were trying to get this info as a normal
consumer, I would go the libc route, since it's likely more cross platform.

On Thu, Nov 17, 2016 at 9:43 AM Kamal Marhubi notifications@github.com
wrote:

Yeah, I would do it with those. If you think a parser is better, that's
also something that I could do.


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJx8rUd_4Yi9MLrVdPWH9nNQTeTdUX_ks5q_JIegaJpZM4K1lSf
.

Apparently prlimit(2) is Linux specific, and was only added in 2.6.36. The Centos 6 series uses 2.6.32, and will receive full updates through this May, and maintenance updates through 2020. So maybe the parser is the way to go.

Hi,

I'm in need for that feature and might target more than Linux. I started something yesterday but I never really used nom and I'm still a beginner with rust, so this might take some days.

@kamalmarhubi do you have something on your side ? Or is it okay for me to do it ?

Merged in #22, will cut a release soon (I want to get the fix in #21 in as well).