Signals tests are unreliable #7
Labels
Comments
webknjaz
added a commit
that referenced
this issue
Mar 11, 2020
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Feb 11, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Feb 11, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Mar 13, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Mar 13, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Mar 13, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Mar 21, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
webknjaz
added a commit
that referenced
this issue
Mar 21, 2021
This patch works around an issue described in #7 by also comparing the stat of PID files. Otherwise it misses cases when PID file gets recreated faster that the check loop hits another existence check.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tests under magicbus/test/test_signals.py spawn processes and send signals to them. Then they use
magicbus.plugins.opsys.PIDFileplugin to wait for subprocess to reload. Itsjoin()method waits for the PID file to stop existing and then exits.The problem is that when receiving certain signals, subprocesses "reload", not exit permanently. And that reloading flow recreates the PID. This works in some envs that are rather slow (namely Travis CI) but on my laptop, it blocks on
join()forever because the subprocess reloads and creates a new PID file faster than thejoin()makes another iteration of its loop. Sojoin()"thinks" that this file keeps existing which in fact is not true because it's a new file now.And I think this is what's happening in AppVeyor CI too: https://ci.appveyor.com/project/CherryPy/magicbus/builds/31405204/job/61xrbpxhyurlx0w0#L78.
So this test suite works incidentally. It must be made more robust.
This also means that
magicbus.plugins.opsys.PIDFile.join()implementation is buggy and has to be refactored.The text was updated successfully, but these errors were encountered: