Get the current working directory of a particular process by pid

As you can see from readme and what shows up in https://crates.io/crates/libproc, we need to update the docs with the new methods added by contributors (like @dalance )

Or, do proper docs, and github pages or something that uses rust's great doc comments!

Currently the test/doctest is

/// # Examples
/// ```
/// use libproc::libproc::proc_pid::regionfilename;
///
/// // This checks that it can find the regionfilename of the region at address 0, of the init process with PID 1
/// match regionfilename(1, 0) {
///     Ok(regionfilename) => println!("Region Filename (at address = 0) of init process PID = 1 is '{}'", regionfilename),
///     Err(message) => assert!(true, message)
/// }
/// ```

So, when there is a problem it does assert(true) and hence never fails.
When asserting false it returns an "Invalid utf-8 sequence" error and fails.

We should understand this call and find a way to test it successfully.

Improve overall docs - I need to learn how to properly document modules, structs, traits and functions in rust following the bets guidelines.

A couple of functions need descriptions or links to the apple docs on the subject

As mentioned in #22 I don't really like how the external API looks - but I still need to learn rust best practices here.

So, sorry if ugly in the meantime.

Suggestions for improvements or PRs from people who know how it should be done are very welcome.

Hey, first of all thanks for the efforts for making this library!
I have an optimization idea for listpids:
https://github.com/andrewdavidmackenzie/libproc-rs/blob/master/src/libproc/proc_pid.rs#L232

let mut pids: Vec<u32> = Vec::with_capacity(PID_MAX);

Function allocates (99999 * 4 / 1024) =~ 390kb of space for a buffer which is not that bad by modern standards but still unnecessary because it's possible to retrieve the desired buffer size beforehand by calling proc_listpids in a special way like this:

int numberOfProcesses = proc_listpids(PROC_ALL_PIDS, 0, NULL, 0);

Example code at the bottom of the question: https://stackoverflow.com/q/3018054

avoid that horrible API a bit

I guess this can be done by listing the entries in /proc and filtering for numeric values.
There doesn't seem to be any other recommended syscall or similar to do it.

e.g. linux variant of listpids() in proc_pid.rs

I'm running into an issue compiling in nixpkgs environment. Building master right now, I get:

   Compiling libproc v0.12.0 (/private/tmp/libproc-rs)
error[E0432]: unresolved import `crate::osx_libproc_bindings::proc_pid_rusage`
  --> src/libproc/pid_rusage.rs:12:5
   |
12 | use crate::osx_libproc_bindings::proc_pid_rusage;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------
   |     |                            |
   |     |                            help: a similar name exists in the module: `PROC_PID_RUSAGE`
   |     no `proc_pid_rusage` in `osx_libproc_bindings`

This happens with either v10 or v11 sdk. Does the generation of this part depend on some extra headers I should have available? Anything else I can provide to debug this?

This happens with rust 1.63

CHeck the list of methods implemented as listed in readme. If there are any important ones missing, then create issues for them.

Improve the docs in docs.rs that a user of the lib would consult, to make api methods available more obvious and easier to understand.

Put some of the readme contents as crate level docs so readers know what they are getting when they go direct to docs.rs

Looks like it needs to run as root :-(

I tried libc::pthread_self. But it seems there is a fixed offset between the value fetched from libc::pthread_self and the value fetched from listpidinfo::<ListThreads>. Don't know why.

Code:

fn main() {
    use std::sync::{Mutex, Arc};
    use std::thread;
    use std::time::Duration;

    let mut ptids = Arc::new(Mutex::new(vec![unsafe { libc::pthread_self() }]));
    let mut threads = vec![];
    for _ in 0..3 {
        let ptids = ptids.clone();
        threads.push(thread::spawn(move || {
            let mut ptids = ptids.lock().unwrap();
            (*ptids).push(unsafe { libc::pthread_self() });
            drop(ptids);
            thread::sleep(Duration::from_millis(1000));
        }));
    }

    thread::sleep(Duration::from_millis(500)); // wait for creating threads
    let pid = std::process::id() as i32;
    let info = pidinfo::<TaskAllInfo>(pid, 0).unwrap();
    let tids = listpidinfo::<ListThreads>(pid, info.ptinfo.pti_threadnum as usize).unwrap();

    println!("tids from pthread_self: {:?}", ptids.lock().unwrap());
    println!("tids from listpidinfo: {:?}", tids);

    threads.into_iter().for_each(|t| t.join().unwrap());
}

Output:

tids from pthread_self: [4509474304, 123145435578368, 123145439797248, 123145437687808]
tids from listpidinfo: [4509474528, 123145435578592, 123145437688032, 123145439797472]

Any help? @andrewdavidmackenzie

Hi,

The latest version uses std::ptr::from_mut (it looks like to fix a clippy warning), but that was only just stabilized in 1.76.0.

Nushell is building on 1.74 at the moment, and can't build anymore with the latest version. This is a breaking change to minimum Rust version.

See: nushell/nushell#12182 (comment)

Would you please replace with something that works on 1.74, or bump major and clarify minimum rust version in Cargo.toml?

Thanks.

Get the path to the file being executed as the pid

Was noticing on my mbp with an M1 Pro, the virtual memory usage is being listed as really high numbers. Nushell uses libproc get query this info, and all the virtual memory numbers that come back are hundreds of gigs.

Is there something we should be doing on the nushell side or is this libproc-related?

Should be able to take clippy out of the matrix

for proc_pid.rs:

// Added in 10.7
// int proc_listallpids(void * buffer, int buffersize) __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_1);
// int proc_listpgrppids(pid_t pgrpid, void * buffer, int buffersize) __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_1);
// int proc_listchildpids(pid_t ppid, void * buffer, int buffersize) __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_1);
// int proc_pidfileportinfo(int pid, uint32_t fileport, int flavor, void *buffer, int buffersize) __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);

Hi, I'm interested in the libproc functionality for a Linux project I'm working on, but it looks like the project might be abandoned/dormant? Are there any plans to continue the project and what barriers are in the way of it working on linux?

I'm more than happy to contribute to attempt to get Linux support working and help out in general. Just let me know 😄

I want to publish a crate that depends on libproc, but I can't because the current published version has the double-free bug fixed in this commit. e7d2319

System: macOS 11.0.1

Cargo.toml:

[package]
# ...

[dependencies]
libproc = "0.12.0"

Error:

   Compiling libproc v0.12.0
error: failed to run custom build command for `libproc v0.12.0`

Caused by:
  process didn't exit successfully: `<PROJECT PATH>/target/debug/build/libproc-7ab682cfcd895988/build-script-build` (exit status: 101)
  --- stderr
  <HOME>/.cargo/registry/src/github.com-1ecc6299db9ec823/libproc-0.12.0/libproc_rs.h:1:10: fatal error: 'libproc.h' file not found
  <HOME>/.cargo/registry/src/github.com-1ecc6299db9ec823/libproc-0.12.0/libproc_rs.h:1:10: fatal error: 'libproc.h' file not found, err: true
  thread 'main' panicked at 'Failed to build libproc bindings: ()', <HOME>/.cargo/registry/src/github.com-1ecc6299db9ec823/libproc-0.12.0/build.rs:9:10
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/62b272d25c5bb8b6bb8ac73797d82b8b9a1eabda/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/62b272d25c5bb8b6bb8ac73797d82b8b9a1eabda/library/core/src/panicking.rs:142:14
     2: core::result::unwrap_failed
               at /rustc/62b272d25c5bb8b6bb8ac73797d82b8b9a1eabda/library/core/src/result.rs:1805:5
     3: core::result::Result<T,E>::expect
               at /rustc/62b272d25c5bb8b6bb8ac73797d82b8b9a1eabda/library/core/src/result.rs:1055:23
     4: build_script_build::main
               at ./build.rs:6:20
     5: core::ops::function::FnOnce::call_once
               at /rustc/62b272d25c5bb8b6bb8ac73797d82b8b9a1eabda/library/core/src/ops/function.rs:248:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

If I can give you any more info, please notify me in the comment.

Hey!

This library is great, but unfortunately I ran into an issue where to collect process memory, apparently I need to use libproc::pid_rusage? But that seems to be only available on Mac OS?

The docs say this "was added in Mac OS X 10.9" but it wasn't clear to me it was not available on other OSs.

What I want is probably just "resident memory" (in lay terms, how much RAM the process is using). Is there a way to get that which works on all Windows, Linux and Mac OS?

Thanks.

I assume that this check will progress to stable before too long and break everything, so we will have to fix it.

Apart from disabling from the root of the crate, not sure there is a lot we can do, as this is in bindgen generated code.

Compiling libproc v0.11.1 (/Users/runner/work/libproc-rs/libproc-rs)
error: reference to packed field is unaligned
 --> /Users/runner/work/libproc-rs/libproc-rs/target/debug/build/libproc-ec97c35fbd[55](https://github.com/andrewdavidmackenzie/libproc-rs/runs/6163681943?check_suite_focus=true#step:4:55)2ca1/out/osx_libproc_bindings.rs:3:373846
  |
3 | ...state))) ; assert_eq ! (unsafe { & (* (:: std :: ptr :: null :: < searchstate > ())) . ss_union_flags as * const _ as usize } , 0usize...
  |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(unaligned_references)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
  = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
  = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)

Sometimes the tests fail due to a segfault, running locally this can be as infrequent as 1 in 10 to 20 runs.

So, no idea what's causing this - it makes me suspicious of the stability/usability of the underlying libproc.a library on more recent Mac OS X versions. But the 'C' version never seems to fail, so I'm not sure....

Needs investigation that's for sure.

Even macos 11 images are deprecated on GH Actions and will need to be dropped soon.

Update Cargo.toml, readme.md, pid_rusage.rs

It would be great for someone who understands more of the details of the Darwin kernel structures to help add more informative doc comments for them in the code

I feel like pidpath() should return Result<PathBuf, String> since a path is not required to be UTF8, no?

Ass Apple updates darwin, it adds some new variants (flavors) available to some API calls (e.g. proc_pidinfo()).

Create a mapping of
XNU version --> What variants available --> What versions of mac os support them

So we can make conditional code on OS versions, and maybe also allow to detect the OS version at runtime and hence check the flavors that can be used in some api calls.

The GH Action claims to post to my site, but it's not working or not there - so fix it and add a link in readme or cargo.toml (for crates.io) or something.

Not sure how to test those calls reliable yet. Maybe need to use some other macos API to create a thread or a workqueue?

I have started using "act" on another rust project and runs fine, but here it reports an error related to not finding "rustup" in PATH.

Looking at darwin errno.h source I should be checking for errno != 0, not < 0, as errnos are positive.

error 1:

error[E0425]: cannot find function `listpids` in this scope
  --> external/rust/crates/libproc-rs/src/processes.rs:68:5
   |
68 |     listpids(filter)
   |     ^^^^^^^^ not found in this scope
   |
help: consider importing this function
   |
1  + use crate::libproc::proc_pid::listpids;
   |

error: aborting due to previous error

error 2:

error[E0308]: mismatched types
   --> external/rust/crates/libproc-rs/src/processes.rs:69:14
    |
69  |     listpids(filter)
    |     -------- ^^^^^^ expected `ProcType`, found `ProcFilter`
    |     |
    |     arguments to this function are incorrect
    |
note: function defined here
   --> external/rust/crates/libproc-rs/src/libproc/proc_pid.rs:185:8
    |
185 | pub fn listpids(proc_types: ProcType) -> Result<Vec<u32>, String> {
    |        ^^^^^^^^ --------------------

error[E0308]: mismatched types
  --> external/rust/crates/libproc-rs/src/processes.rs:69:5
   |
68 | pub fn pids_by_type(filter: ProcFilter) -> io::Result<Vec<u32>> {
   |                                            -------------------- expected `Result<Vec<u32>, std::io::Error>` because of return type
69 |     listpids(filter)
   |     ^^^^^^^^^^^^^^^^ expected `Result<Vec<u32>, Error>`, found `Result<Vec<u32>, String>`
   |
   = note: expected enum `Result<_, std::io::Error>`
              found enum `Result<_, String>`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0308`.
18:21:05 ninja failed with: exit status 1

#### failed to build some targets (4 seconds) ####

No problem in local for me, even after updating rust to 1.47 - so not sure what's the problem - it just seems to hang and then travis kills the build after 10mins.

Add own error types? use io::Result subtype? stay with Strings?

Currently, listpids sets the typeinfo argument to proc_listpids to 0:

That makes perfect sense for ProcType::ProcAllPIDS, but when using any of the other ProcType variants, a call to proc_listpids only makes sense if you pass in the matching ID as the typeeinfo value, e.g. for ProcType::ProcPGRPOnly, you can pass in the program group id (PGID) and get only those processes that are part of the process group.

To illustrate, you could try creating a process with the command_group crate, such as a shell script that spawns a couple of sleep <large number> background processes. This gets you a GroupChild struct with a .id() method returning the process group ID. If you then use proc_listpids(proc_pid::ProcType::ProcPGRPOnly, child.id(), buffer_ptr, buffer_size) the buffer is filled with the PIDs of the processes in that process group.

The (abandoned?) darwin-libproc crate has separate functions for each ProcType variant to pass in the corresponding identifiers.

Can libproc-rs please offer the same options?

latest as of time of writing is 14.1.1
Look at change log or diffs of darwin source

See #76

but it took about 12h for macos-12 instances to become available to run on this PR, then they failed with no details - so maybe I'll wait before trying to add that to CI...