You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using the fah-gpu-amd container to run the folding@home client on my desktop, as the OS it runs is not supported by ROCm userspace and having a consistent environment is much simpler.
I've noticed if the folding@home client kills a subprocess for some reason (pausing, or if some bug is detected), the process ends up as a zombie and the folding@home client never cleans it up. As folding@home is PID 1, there is no other reaper and the process continue to exist and the client gets wedged, unable to respawn the work unit. Note: this happens to both GPU and CPU WU on the same machine.
Could the folding@home client be updated to reap these processes? Otherwise, could the containers be updated with a different PID 1 to reap these dead children? If the new PID 1 is wanted, I could take a look at creating an appropriate PR.
The text was updated successfully, but these errors were encountered:
I'm using the fah-gpu-amd container to run the folding@home client on my desktop, as the OS it runs is not supported by ROCm userspace and having a consistent environment is much simpler.
I've noticed if the folding@home client kills a subprocess for some reason (pausing, or if some bug is detected), the process ends up as a zombie and the folding@home client never cleans it up. As folding@home is PID 1, there is no other reaper and the process continue to exist and the client gets wedged, unable to respawn the work unit. Note: this happens to both GPU and CPU WU on the same machine.
Could the folding@home client be updated to reap these processes? Otherwise, could the containers be updated with a different PID 1 to reap these dead children? If the new PID 1 is wanted, I could take a look at creating an appropriate PR.
The text was updated successfully, but these errors were encountered: