ExeWithContext returns an error with a Go binary on newer versions of macOS

[MDrakos]

Describe the bug
The ExeWithContext function here expects a specific number of ftxt entries before it extract the executable file path. It appears that on newer versions of macOS this output has changed.

To Reproduce
Passing the following code a running Go binary creates an error. I haven't tested with other running processes.

❯ CGO_ENABLED=0 go run main.go 64030
Could not get executable of process: missing txt data returned by lsof
exit status 1

package main

import (
	"errors"
	"fmt"
	"os"
	"strconv"

	"github.com/shirou/gopsutil/v3/process"
)

func main() {
	if err := run(); err != nil {
		fmt.Println(err)
		os.Exit(1)
	}
}

func run() error {
	if len(os.Args) != 2 {
		return errors.New("Usage: process <pid>")
	}

	pidArg := os.Args[1]
	pid, err := strconv.Atoi(pidArg)
	if err != nil {
		return fmt.Errorf("Could not parse pid: %w", err)
	}

	proc, err := process.NewProcess(int32(pid))
	if err != nil {
		return fmt.Errorf("Could not create process: %w", err)
	}

	_, err = proc.Exe()
	if err != nil {
		return fmt.Errorf("Could not get executable of process: %w", err)
	}

	return nil
}

When I run the lsof command I can see only one ftxt line in the output.

Expected behavior
The proc.Exe() call does not fail and returns the executable file path.

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]
• Mac OS: [paste the result of sw_vers and uname -a

~
❯ sw_vers
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224

~
❯ uname -a
Darwin M1-MacBook-Pro-6.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 arm64

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

Additional context
For the product I'm working on we have an integration test suite that runs on an older version of macOS. The issue does not appear to be present there. Below are the details from the integration test runner:

Operating System
  macOS
  11.7.10
  20G1427
Runner Image
  Image: macos-11
  Version: 20240127.1
  Included Software: https://github.com/actions/runner-images/blob/macOS-11/20240127.1/images/macos/macos-11-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/macOS-11%2F20240127.1

[Lomanic]

Can you share with us the result of lsof -p PID -Fpfn, with PID the pid of the offending process (command is used here)?

[MDrakos]

Sure, here is the output of the command with a similar process

❯ lsof -p 59152 -Fpfn
p59152
fcwd
n/Users/mike/work/testing/Perl-5.36/Perl-5.36
ftxt
n/Users/mike/Library/Caches/activestate/132bf798/exec/perl
f0
n/dev/ttys003
f1
n/dev/ttys003
f2
n/dev/ttys003
f4
ncount=0, state=0xa
f5
n->0xf36292a772dd4ebc
f6
n->0xeca79050e663a168

[shirou]

Thank you for the information. From the code, ftxt must appear twice or more. But only once on your information.

Perhaps the lsof version has been updated to 4.93 or later. I tested on old version of macOS which has lsof version 4.91, and the output has multiple ftxt.
Could you run lsof -v to confirm?

[MDrakos]

Sure, here is the output:

❯ lsof -v
lsof version information:
    revision: 4.91
    latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
    latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
    latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
    configuration info: libproc-based
    Anyone can list all files.
    /dev warnings are disabled.
    Kernel ID check is disabled.

For what it's worth, we have an integration test suite that was running on version 11 of macOS that did not have this problem so you're theory could be correct.

[shirou]

Thank you for the information. This means that the code may need to be changed depending on the number of ftxt contained in the output. This is difficult to make a PR right now for me, but I will give it a try. Or contribution is always welcome!

[MDrakos]

Closing this as the fix has now been merged.