Open jennifer-richards opened 6 years ago
I believe this is caused by interplay between threading and forking in the main process. Disabling the TRP threads (or keeping them from being started by turning off peering) seems to eliminate this problem. The monitoring processes exit as expected.
I've reported the underlying problem as #85. As an immediate workaround, replacing our exit()
calls with abort()
in the TID and monitoring processes seems to prevent sleeping processes from hanging around. Given that, I am lowering the priority, but this is not a pleasant situation so I am leaving this open.
After handling a monitoring request, subprocesses are being left in the sleeping state instead of being cleaned up.
This is similar to #64 / #4, except the processes are using no CPU.
Attaching to one with gdb shows that it is in the exit handler - this may be related to some exit problems with mech_eap.