This can be reproduced in isolation (i.e. it's not dependent on other tests running in the same run, nor on concurrent test runs)
Happens occasionally, but not often.
Looks like sometimes a lemming process is re-used after SIGHUP, instead of exiting and restarting with new configuration. Therefore, instead of getting one-more-dead-process than last count at the point of examination, the dead process count unexpectedly remains the same.
No idea what the underlying cause is yet. Some sort of race condition, I expect -- maybe a seconds-granularity timestamp issue somewhere? It might be fixable just by adding a "sleep(1)" in a judicious spot in the test, but since it happens rarely to begin with, it's hard to verify whether such a change has actually fixed something, hidden something, or done nothing.
This can be reproduced in isolation (i.e. it's not dependent on other tests running in the same run, nor on concurrent test runs)
Happens occasionally, but not often.
Looks like sometimes a lemming process is re-used after SIGHUP, instead of exiting and restarting with new configuration. Therefore, instead of getting one-more-dead-process than last count at the point of examination, the dead process count unexpectedly remains the same.
No idea what the underlying cause is yet. Some sort of race condition, I expect -- maybe a seconds-granularity timestamp issue somewhere? It might be fixable just by adding a "sleep(1)" in a judicious spot in the test, but since it happens rarely to begin with, it's hard to verify whether such a change has actually fixed something, hidden something, or done nothing.