As requested here.

These were generated on OpenBSD-current on a Raspberry Pi 4.

Can you tell me how to test the build and run the test suite? I don't know anything about golang!

Fixes #992

I am trying to get cpu usage for a process. However, I am getting 0 as the value always. Below is my sample code. I am using telegraf procstat plugin. Even there it's returning 0 value

` func main() {

var pid int32
pid = 10172
proc, _ := process.NewProcess(pid)
p, err := proc.Percent(time.Duration(0))
if err != nil {
   fmt.Println(err)
}

}`

Thanks

I noticed CPU outputs value of MHz instead of number on CPUs. I thought CPU is used to output number of physical CPUs.

I think dmesg might help here to get the right number. Here are a few examples from our servers

• (2phys CPUs no HT) FreeBSD/SMP: 2 package(s) x 4 core(s) hw.ncpu=8
• (1 phys CPUs) FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads hw.ncpu=4
• (1 phys CPUs) FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads hw.ncpu=8
• (1 phys CPUs) FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads hw.ncpu=12

I would like to support device mapper naming in linux for the disk module.

It's not as exotic as it sounds, eg LVM devices get a mapper name; but my main interest is is multipath devices.

to get the name, there's following https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block-dm

so given device name abc it is as easy as trying to get the content of /sys/block/abc/dm/name. it will be empty for non-dm devices and for older kernels or system without /sys mounted

my main question is: would such feature get merged? and if so, what attributename can i use for that?

i would implement it similar to getSerialNumber and maybe add it in IOCounter as d.DMName = getDeviceMapperName(), similar to the way the serial number is added.

CPU metrics are broken on OpenBSD 7.0-CURRENT as described in #1239. I believe that the problem is the multiplication of the CPU incrementer by 2 when the code walks through the available CPUs to gather CPU time metrics. The code makes uses of the KERN_CPTIME2 sysctl to fetch per-CPU time metrics.

Looking at the kernel code behind this particular sysctl, we have this.. As you can see, it's calling a CPU_INFO_FOREACH macro and iterating through the results until it has the info for the requested CPU. This macro is defined per-architecture and in every one that I found, it's just iterating through cpu_info structs defined here.

I can't find anything that leads me to believe that this Go code should be incrementing by anything other than 1.

In the entire OpenBSD codebase, there's only one use of the KERN_CPTIME2 sysctl and that's in snmpd's source code, which iterates through the CPUs and it does this by incrementing the counter by 1.

This particular code ^ hasn't changed since 2016 and I'll bet it still works. :-)

Here's another clue. As I mentioned, the guts of this syscall is just iterating through cpu_info struct. I looked around for other uses of this struct and found code for the new OpenBSD debugger. There are different implementations for different architectures, but for amd64, it also increments through CPUs by 1.

Here is a PR to fix this. I only have one OpenBSD machine to test on, a simple Dell Optiplex workstation.

By assuming virtualization environment won't change during a the program's runtime, we can cache common/common_linux.Virtualization() with a simple map to reduce amount of system calls. I first mentioned this issue at 890

The go.mod file in this repo does not specify the /v2 tag so if this module is imported in any project, it will be imported with +incompatible From the official documentation (https://github.com/golang/go/wiki/Modules)

The module path (such as module foo/v2) declared at the start of a module's go.mod file is both: the definitive declaration of that module's identity the definitive declaration of how that module must be imported by consuming code

A module can import a v2+ package that has not opted in to modules itself. A non-module v2+ package that has a valid v2+ semver tag will be recorded with an +incompatible suffix in the importing module's go.mod file. The +incompatible suffix indicates that even though the v2+ package has a valid v2+ semver tag such as v2.0.0, the v2+ package has not actively opted in to modules and hence that v2+ package is assumed to have not been created with an understanding of the implications of Semantic Import Versioning and how to use major versions in import paths. Therefore, when operating in module mode, the go tool will treat a non-module v2+ package as an (incompatible) extension of the v1 version series of the package and assume the package has no awareness of Semantic Import Versioning, and the +incompatible suffix is an indication that the go tool is doing so.

Tested this on centos linux and saw this in my go.mod file github.com/shirou/gopsutil v2.18.12+incompatible When I tested this, the current tag was 2.19.03 My go version go version go1.11 linux/amd64

on bedrock linux installs, gopsutil improperly detects the operating system as the operating system of the strata the program is being run from. this pull request adds in another utility function that detects the /bedrock folder at the root of the system and if it finds it, it changes the files being read from and properly detects the operating system as being bedrock linux

Describe the bug There is a deprecation messages while building code with gopsutil v3.

# github.com/shirou/gopsutil/disk
iostat_darwin.c:28:2: warning: 'IOMasterPort' is deprecated: first deprecated in macOS 12.0 [-Wdeprecated-declarations]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:132:1: note: 'IOMasterPort' has been explicitly marked deprecated here
# github.com/shirou/gopsutil/host
smc_darwin.c:75:41: warning: 'kIOMasterPortDefault' is deprecated: first deprecated in macOS 12.0 [-Wdeprecated-declarations]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:123:19: note: 'kIOMasterPortDefault' has been explicitly marked deprecated here

To Reproduce

package main

import (
	_ "github.com/shirou/gopsutil/cpu"
	_ "github.com/shirou/gopsutil/disk"
	_ "github.com/shirou/gopsutil/host"
	_ "github.com/shirou/gopsutil/mem"
)

func main() {}

Expected behavior There isn't any messages about deprecation.

Environment (please complete the following information):

• [x] Mac OS: [paste the result of sw_vers and uname -a

ProductName:	macOS
ProductVersion:	12.0.1
BuildVersion:	21A559

Darwin MacBook-Pro.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

Hi, @shirou I write windows service package to implement like psutil win_services.

usage:

import (
	"fmt"
	"log"

	"github.com/shirou/gopsutil/winservices"
)

func main() {
        name := "MySQL57"
	srv, err := winservices.NewService(name)
	if err != nil {
		log.Fatalf("get service by name error, %s", err)
	}
	if err := srv.GetServiceDetail(); err != nil {
		log.Fatalf("get service %s error, %s", name, err)
	}

       services, err := winservices.ListServices()
	if err != nil {
		log.Fatal(err)
	}
}

implement #524, please check it. I don't know how to write test code for this feature, can you tell me? thanks :)

updated win32_Processor struct to exclude (unused) LoadPercentage field. The loadpercentage takes linearly more time as the # of sockets increases. By default vSphere maps 1 vCPU to 1 socket, resulting in very poor performance when getting CPU info against, saying, 40 vCPU VM (basically 40 sockets as seen by the VM).

Here is the before and after time comparison:

changes:

for cpu: since Win32_Processor is a public struct, created a substruct named: Win32_ProcessorWithoutLoadPct for use in all queries without breaking any potential usage of the public api.

for v3/cpu: since the struct now is private, simply removed LoadPercentage

Bumps golang.org/x/sys from 0.3.0 to 0.4.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the bug I'm getting a "C source files not allowed when not using cgo or SWIG: iostat_darwin.c" error when compiling when trying to compile go-btfs which has a dependency on go-sutil. I need to use CGO so CGO=0 is not doable for me, issue is happening for arm64 and x86_64 as well.

Exact output error:

package github.com/bittorrent/go-btfs/cmd/btfs imports github.com/bittorrent/go-btfs/chain imports github.com/bittorrent/go-btfs/core/commands/storage/path imports github.com/shirou/gopsutil/v3/disk: C source files not allowed when not using cgo or SWIG: iostat_darwin.c make: *** [ios-arm64] Error 1

To Reproduce

v3.22.12

	CGO_ENABLED=1 \
	GOOS=darwin \
	GOARCH=arm64 \
	SDK=iphoneos \
	SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk \
	CC=$(PWD)/clangwrap.sh \
	CGO_CFLAGS="-fembed-bitcode -Wno-undef-prefix" \
	go build -buildmode=c-archive -tags ios -o $(IOS_OUT)/arm64.a .

Expected behavior Compiling completed with no issues

Environment (please complete the following information):

• [ ] Windows: [paste the result of ver]

• [ ] Linux: [paste contents of /etc/os-release and the result of uname -a]

• [X] Mac OS: ProductName: macOS ProductVersion: 13.1 BuildVersion: 22C65 Darwin Simbads-MacBook-Air.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103 arm64

• [ ] FreeBSD: [paste the result of freebsd-version -k -r -u and uname -a]

• [ ] OpenBSD: [paste the result of uname -a]

Additional context [Cross-compiling? Paste the command you are using to cross-compile and the result of the corresponding go env] GO111MODULE="" GOARCH="arm64" GOBIN="" GOCACHE="/Users/simbadmarino/Library/Caches/go-build" GOENV="/Users/simbadmarino/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="arm64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/simbadmarino/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/simbadmarino/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64" GOVCS="" GOVERSION="go1.19.4" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/simbadmarino/Documents/btfs-sharedLib/go.mod" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/89/7_dkrhfd345107kdvp3gk4p40000gn/T/go-build1188434045=/tmp/go-build -gno-record-gcc-switches -fno-common"

MakeFile:

	CGO_ENABLED=1 \
	GOOS=darwin \
	GOARCH=arm64 \
	SDK=iphoneos \
	SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk \
	CC=$(PWD)/clangwrap.sh \
	CGO_CFLAGS="-fembed-bitcode -Wno-undef-prefix" \
	go build -buildmode=c-archive -tags ios -o $(IOS_OUT)/arm64.a .

clangwrap.txt

Any support is greatly appreciated. Thanks

Describe the bug

print the error information

gopsutil: unexpected processor queue length counter error, please file an issue on github: err

To Reproduce

// paste example code reproducing the bug you are reporting

I am not sure what api cause this error

Expected behavior

It should works without any error information.

Environment (please complete the following information):

• [x] Windows: [paste the result of ver]
• [ ] Linux: [paste contents of /etc/os-release and the result of uname -a]
• [ ] Mac OS: [paste the result of sw_vers and uname -a
• [ ] FreeBSD: [paste the result of freebsd-version -k -r -u and uname -a]
• [ ] OpenBSD: [paste the result of uname -a]

Additional context [Cross-compiling? Paste the command you are using to cross-compile and the result of the corresponding go env]

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Admin\AppData\Local\go-build
set GOENV=C:\Users\Admin\AppData\Roaming\go\env  
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Admin\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Admin\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.com.cn,direct   
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.3
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\Admin\go\xx\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\Admin\AppData\Local\Temp\go-build2193561186=/tmp/go-build -gno-record-gcc-switches
PS C:\Users\Admin\go\src\xxx>

If need any additional information, please let me known.

These two commits will hopefully help bring support for NetBSD to the project. I have not been able to verify if these changes are correct yet ("go test" did not yield anything apparently useful). Please review before merging, and do so only if you feel like it is not expected to break anything new.

For these changes, I have simply copied the OpenBSD files as NetBSD, as the two systems are usually very close to one another. As such I think at least some things should work once the module is confirmed to build.

Describe the bug

In disk_windows.go func PartitionsWithContext not used flag "all" Always return all type of drive

adding a flag analysis in lpBuffer cycle if !all && (typeret==2 || typeret==4 || typeret==5) { continue }