Summary

• OS: macOS 15.7.3
• Architecture: ARM
• Psutil version: 7.2.1
• Python version: 3.10.11
• Type: core

Description

p.cmdline() raises OSError "Errno 0 (originated from sysctl(KERN_PROCARGS2)"

The relevant traceback is:

  My code:
    cmdline = p.cmdline()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/psutil/__init__.py", line 748, in cmdline
    return self._proc.cmdline()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/psutil/_psosx.py", line 347, in wrapper
    return fun(self, *args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/psutil/_psosx.py", line 405, in cmdline
    return cext.proc_cmdline(self.pid)
OSError: [Errno 0] Undefined error: 0 (originated from sysctl(KERN_PROCARGS2))

This happened once during test in a GitHub Actions run, on macOS with Python 3.10. The log for that is https://github.com/pywbem/pywbemtools/actions/runs/21150786886/job/60826939420. This test on that code level of my project ran several times before, and a re-run of the Actions job did not cause it to re-occur. On my local macOS (15.6) on Python 3.10, I ran the test module that failed 10 times in a loop, but also could not reproduce it.

The project where the error occurred develops the "pywbemlistener" command. That command has subcommands. The error happened in the "list" subcommand which lists running pywbemlistener processes. The "list" subcommand has the following loop:

    for p in psutil.process_iter():
        try:
            cmdline = p.cmdline()                       # <-- This raised the OSError
        except (psutil.AccessDenied, psutil.ZombieProcess,
                psutil.NoSuchProcess):
            # Ignore processes we cannot access or that ended meanwhile
            continue

        . . . # inspect cmdline to find pywbemlistener processes

The test where the error happened starts and stops pywbemlistener processes, so it is well possible that a process from a previous testcase was still in a weird state when the "list" command (which is used in the test teardown) ran.

As a mitigation, I plan to also ignore OSError with errno=0, but I wanted to report this issue nevertheless.