ListProcesses fails with 3.4.2.0 server and 3.4.0.1 client
atkinsj opened this issue · comments
Hi all,
Is this expected? I upgraded the server to 3.4.2.0 via the docker images but I'm interacting with a macOS host running 3.4.0.1 still. ListProcess generates the below:
Traceback (most recent call last): File "/usr/share/grr-server/lib/python3.6/site-packages/grr_response_server/flow_base.py", line 672, in RunStateMethod method(responses) File "/usr/share/grr-server/lib/python3.6/site-packages/grr_response_server/flows/general/processes.py", line 58, in IterateProcesses responses.status) grr_response_server.flow_base.FlowError: Error during process listing message FlowStatus { backtrace : 'Traceback (most recent call last):\n File "site-packages/grr_response_client/actions.py", line 151, in Execute\n File "site-packages/grr_response_client/client_actions/standard.py", line 417, in Run\n File "site-packages/grr_response_client/client_actions/standard.py", line 408, in ListProcessesFromClient\n File "site-packages/grr_response_core/lib/rdfvalues/client.py", line 351, in FromPsutilProcess\n File "site-packages/psutil/__init__.py", line 773, in exe\n File "site-packages/psutil/_psosx.py", line 339, in wrapper\n File "site-packages/psutil/_psosx.py", line 420, in exe\nFileNotFoundError: [Errno 2] No such file or directory\n' client_id : 'C.c491d7460266702c' cpu_time_used : message CpuSeconds { system_cpu_time : 0.03156070411205292 user_cpu_time : 0.22054502367973328 } error_message : "FileNotFoundError(2, 'No such file or directory'): [Errno 2] No such file or directory" flow_id : '2CF95699' network_bytes_sent : 93026 request_id : 1 response_id : 250 status : ERROR }
--
@atkinsj - the error seems to happen purely on the client side. I'd expect it to not be related to the server upgrade. Is the error easily reproducible on the client in question?
Yup -- happens 100% of the time.
I think this might be related to giampaolo/psutil#1738
Seems like a bug in the client.
Huh, good catch. Fortunately the client was my box and a reboot confirms it's resolved. Hopefully that gets fixed upstream, thanks!