-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redis 6 on Mac won't halt on SIGTERM if the temp directory has been deleted #13
Comments
Thanks for the report. I have also seen the report to Redis itself and understand the situation. There are several possible ways to do this.
Let me think some more about what to do. Your pull requests are also welcome. |
I have implemented the above 2 methods. I was also able to write a test that reproduced the situation, so I was able to solve the problem. ref. #15 |
Changelog diff is: diff --git a/Changes b/Changes index 8ca38fd..838f99d 100644 --- a/Changes +++ b/Changes @@ -2,6 +2,9 @@ Revision history for Perl extension Test::RedisServer {{$NEXT}} +0.23 2022-02-25T10:07:52Z + - fix the blocking behavior when tmpdir disappears when the server is stopping (issue #13, #15) + 0.22 2022-02-25T01:45:52Z - Update regexp for redis error messages (gregoa, davidcantrell-bb)
Thanks. I've tested with both Redis 5 and 6, and both work just fine now. |
If you create a Test::RedisServer object which doesn't get destroyed until global destruction, and use the default setting of having T::RS create a temp dir for you, then, because the order of destruction is not guaranteed, the directory object may get destroyed (triggering deletion of the directory) before T::RS sends the SIGTERM signal to redis-server.
Redis-server then doesn't stop, because for some reason it seems to want the directory to exist.
I have a work-around in my code, where I supply a temp dir to the constructor, and then call ...->stop in and END block, thus guaranteeing that T::RS stops redis-server while the directory still exists.
I can't think off the top of my head of a better solution which could be applied inside T::RS itself, except perhaps that of sending a SIGKILL instead, but that's a bit icky.
I've only seen this on MacOS, so it may be a platform-specific quirk of Redis - it's definitely a Redis bug at heart and I have also reported it to them: redis/redis#10330
The text was updated successfully, but these errors were encountered: