-
Notifications
You must be signed in to change notification settings - Fork 469
Bug 449182561: Handle SIGTERM irrespective of unmount status #3957
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
base: master
Are you sure you want to change the base?
Conversation
|
Hey there and thank you for opening this pull request! 👋🏼 We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted. Details: |
|
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
The pull request introduces a watchdog timer to forcefully terminate the process if unmounting hangs upon receiving a SIGTERM or SIGINT signal. This is a good solution to prevent the process from getting stuck. My feedback focuses on improving the implementation of this watchdog by using a constant for the timeout, using a more appropriate exit code to signal an abnormal termination, and improving the clarity of the log messages. I've also noted that the use of os.Exit will bypass some graceful shutdown procedures, which is a trade-off to consider.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3957 +/- ##
==========================================
- Coverage 82.77% 82.68% -0.10%
==========================================
Files 148 148
Lines 18030 18062 +32
==========================================
+ Hits 14925 14934 +9
- Misses 2551 2570 +19
- Partials 554 558 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hi @kislaykishore, @ashmeenkaur, your feedback is needed to move this pull request forward. This automated reminder was triggered because there has been no activity for over 24 hours. Please provide your input when you have a moment. Thank you! |
3 similar comments
|
Hi @kislaykishore, @ashmeenkaur, your feedback is needed to move this pull request forward. This automated reminder was triggered because there has been no activity for over 24 hours. Please provide your input when you have a moment. Thank you! |
|
Hi @kislaykishore, @ashmeenkaur, your feedback is needed to move this pull request forward. This automated reminder was triggered because there has been no activity for over 24 hours. Please provide your input when you have a moment. Thank you! |
|
Hi @kislaykishore, @ashmeenkaur, your feedback is needed to move this pull request forward. This automated reminder was triggered because there has been no activity for over 24 hours. Please provide your input when you have a moment. Thank you! |
Bug 449182561: Handle SIGTERM irrespective of unmount status
Bug 449182561: Handle SIGTERM irrespective of unmount status
Please ensure your PR title follows the format:
Example:
feat(api): add user login endpointAvailable types:
feat: A new featurefix: A bug fixdocs: Documentation only changesstyle: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)refactor: A code change that neither fixes a bug nor adds a featureperf: A code change that improves performancetest: Adding missing tests or correcting existing testsbuild: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)chore: Other changes that don't modify src or test filesrevert: Reverts a previous commitDescription
When we are returning from the go routine for signal handler, instead of return we should os.Exit with background thread with sleep 30sec alongside unmount. so that unconditionally the process terminates and does not get stuck in the main thread (What is the suspicion for delay reproduced during internal tests go/gcsfuse-sigterm-handling).
Link to the issue in case of a bug fix.
Testing details
Any backward incompatible change? If so, please explain.