Closes #276

I work with @MOZGIII and @jamtur01 on vector. I implemented this as requested in #276. I think some of the concerns of an implementation in this shape will probably be clear from the PR. However this does at least unblock us in Vector. Obviously please let us know any alterations you'd like me to make!

Signed-off-by: Ian Henry [email protected]

Hello, I had to implement a piece of heim for my needs, let"s share it!

This MR implements heim::net::nic() on Windows using the GetAdaptersAddresses API. It closes #24

It also adds an index() member function for Nics on Windows, macOS and Linux

Hello, i'm new to Heim and rust, i'm building a neon-binding for Heim.

i tried Host module and it works great, but i have a problem with cpu frequency, it returns zero, is there a compatibility issue with neon?

i'm using Windows 10, with AMD cpu and my version of rustc is 1.42.0

heim = { git='https://github.com/heim-rs/heim', features = ["cpu","host","runtime-tokio"] } tokio = { version = "*", features = ["full", "macros"] } neon = "0.4.0"

heres my code

struct CpuFreq;

impl Task for CpuFreq{
    type Output = u64;
    type Error = Error;
    type JsEvent = JsNumber;
    #[tokio::main]
    async fn perform(&self) -> Result<u64> {
        let freq = cpu::frequency().await?;
        Ok(freq.current().get::<units::frequency::millihertz>())
    }
    fn complete(self, mut cx: TaskContext, result: Result<u64>) -> JsResult<JsNumber> {
        match result {
            Ok(cpu) => Ok(cx.number(cpu as f64)),
            Err(err) => cx.throw_error(err.to_string()),
        }
    }
}


pub fn cpu_frequency(mut cx: FunctionContext) -> JsResult<JsUndefined> {
    let f = cx.argument::<JsFunction>(0)?;
    CpuFreq.schedule(f);
    Ok(cx.undefined())
}

register_module!(mut cx, {
    cx.export_function("cpuFrequency", cpu_frequency)?;
    Ok(())
});

i run in node with this

var addon = require('../native');
const { promisify } = require('util');

addon.cpuFrequencyP= promisify(addon.cpuFrequency);

  addon
      .cpuFrequencyP()
      .then(console.log)
      .catch(console.error)

A lot of folks collect host metrics using monitoring tools running inside Docker or Kubernetes. Inside these containers, to access the host system underneath, we need to bind-mount /proc and /sys into the container so the monitoring tool finds the right filesystem. The monitoring tool is then configurable to specify the bind-mount instead of the container's filesystem.

A good example is the Prometheus node_exporter, this setup you can see in their Helm chart for deploying in k8s: https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus-node-exporter/templates/daemonset.yaml). The node_exporter then has some configuration to specify the location of /proc and /sys:

The volumes:

      volumes:
        - name: proc
          hostPath:
            path: /proc
        - name: sys
          hostPath:
            path: /sys

The bind-mount:

          volumeMounts:
            - name: proc
              mountPath: /host/proc
              readOnly:  true
            - name: sys
              mountPath: /host/sys
              readOnly: true

The node_exporter configuration:

     containers:
        - name: node-exporter
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          args:
            - --path.procfs=/host/proc
            - --path.sysfs=/host/sys

It'd be great if heim had the option to configure the location of the relevant filesystems to allow this use case.

I'm trying to compile heim with --target x86_64-unknown-linux-musl and running into the following:

error[E0425]: cannot find value `ST_RELATIME` in crate `libc`
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/heim-disk-0.0.6/src/os/unix/usage.rs:59:32
   |
59 |         const RELATIME = libc::ST_RELATIME;
   |                                ^^^^^^^^^^^ help: a constant with a similar name exists: `MS_RELATIME`

error: aborting due to previous error

This flag isn't defined in rusts musl libc (though it is relatively recently defined upstream in musl itself in 1.1.20) The usage is here: https://github.com/heim-rs/heim/blob/master/heim-disk/src/os/unix/usage.rs#L53-L59

But the comment is confusing me, as it seems to imply that the flag should only exist on macOS targets but then the cfg! macro says the opposite (that it should exist on any non-macOS unix-like).

I wasn't sure if this was an issue for either libc or for heim (perhaps both) but the seeming contradiction in the comments made me think that an issue should be raised here.

copy-pasting from rust-psutil/rust-psutil#80 with some small tweaks

In cjbassi/ytop#75 some users, specifically on MacOS, were running into issues where OsError { source: Os { code: 12, kind: Other, message: "Cannot allocate memory" } } was being returned when trying to update the process list.

I eventually tracked this down to processes() that had a couple of issues leading to this problem:

1. reserve will reserve an additional number of elements represented by the value passed in whereas here it was being given the expected size of all elements in bytes. This was resulting in much more space being reserved than was required.
2. Incorrectly checking for ENOMEM. Based on this document:

If the amount of data available is greater than the size of the buffer supplied, the call supplies as much data as fits in the buffer provided and returns with the error code ENOMEM.

However

Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error.

So I can understand the confusion from the wording, but when it mentions returning ENOMEM this is in the form of errno, not as the return value from the function call. This manifested where the code would check for ENOMEM from sysctl instead of errno, which would cause the error to bubble up instead of appropriately retrying. I think the large reserve size made this case easier to hit since it would stall for more time between reading for the required size and attempting to store.

I would appreciate a thorough look over the changes since it's pretty close to messing with unsafe code and I was able to reproduce the issue on MacOS, but didn't have a chance to verify that the changes work correctly.

/proc/{pid}/stat returns truncated (capped to 15 chars) process name, Process::cmdline could be used to fetch full process name if necessary.

Blocked by #97

ullTotalPageFile and ullAvailPageFile include both the swap and physical memory so in order to get the correct swap memory values the physical memory size/usage needs to be subtracted.

https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-memorystatusex

As per RUSTSEC-2020-0082, version 1.1.1 of the ordered-float dependency fixes a potential cause of UB.

This doesn't appear to affect the master branch, but it does affect v0.0.x versions.

I am using an ARM arch, so the commit fixes project building under non-x86 compatibility architectures by disabling raw-cpuid crate that may work on x86\amd64 archs only.

I can pretty consistently get a crash from this code snippet while querying the users on Windows (Windows 10 Enterprise, Version 1903. Build: 18362.239):

    let mut users = heim::host::users();
    while let Some(user) = users.next().await {
    }

I can only reproduce this when running in release mode. It doesn't seem to repro in debug mode.

ansi_term is Unmaintained

| Details | | | ------------------- | ---------------------------------------------- | | Status | unmaintained | | Package | ansi_term | | Version | 0.12.1 | | URL | https://github.com/ogham/rust-ansi-term/issues/72 | | Date | 2021-08-18 |

The maintainer has adviced this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• nu-ansi-term
• yansi

See advisory page for additional details.

I noticed this project is not receiving any updates and a few security concerns have shown up.

@svartalf are you needing any help maintaining this project?

It seems that there is an error in a dependency to heim when trying to compile heim-net, complaining for a not implemented Error train coming from testdir crate:

Compiling heim-net v0.1.0-beta.2
 Compiling tofnd v0.9.1 (/home/tofnd)
error[E0277]: `?` couldn't convert the error to `heim_common::Error`
--> /home/.cargo/registry/src/github.com-1ecc6299db9ec823/heim-net-0.1.0-beta.2/src/sys/unix/nic.rs:66:37
 |
66 |     let iter = ifaddrs::getifaddrs()?.filter_map(|addr| {
 |                                     ^ the trait `From<nix::Error>` is not implemented for `heim_common::Error`
 |
 = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
 = help: the following implementations were found:
           <heim_common::Error as From<Infallible>>
           <heim_common::Error as From<NulError>>
           <heim_common::Error as From<ParseFloatError>>
           <heim_common::Error as From<ParseIntError>>
         and 2 others
 = note: required because of the requirements on the impl of `FromResidual<std::result::Result<Infallible, nix::Error>>` for `std::result::Result<_, heim_common::Error>`

For more information about this error, try `rustc --explain E0277`.

serde_cbor is unmaintained

| Details | | | ------------------- | ---------------------------------------------- | | Status | unmaintained | | Package | serde_cbor | | Version | 0.11.2 | | URL | https://github.com/pyfisch/cbor | | Date | 2021-08-15 |

The serde_cbor crate is unmaintained. The author has archived the github repository.

Alternatives proposed by the author:

• ciborium
• minicbor

See advisory page for additional details.

If the sensors::temperatures function is spawned into a different thread, it fails with implementation of `std::ops::FnOnce` is not general enough.

MWE:

use futures::StreamExt;
use heim::sensors;

#[tokio::main]
async fn main() {
    tokio::spawn(async {
        sensors::temperatures()
            .collect::<Vec<Result<sensors::TemperatureSensor, heim::Error>>>()
            .await
    });
}