fix: kill running osgrep processes before cleanup#2170
Conversation
…builds The cleanup_osgrep migration removed the binary and data but didn't kill running Node.js processes. MCP servers already loaded in memory would continue running and could attempt to rebuild indexes.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @marcusquinn, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Sun Feb 22 21:25:31 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request correctly addresses the issue of running osgrep processes persisting after the package is uninstalled. The implementation follows a graceful-then-forced kill pattern which is appropriate for Node.js processes. However, there are violations of the repository's style guide regarding error redirection and process matching specificity that should be addressed to maintain consistency and reliability.
| if pgrep -f 'osgrep' >/dev/null 2>&1; then | ||
| print_info "Killing running osgrep processes..." | ||
| pkill -f 'osgrep' 2>/dev/null || true | ||
| # Give processes a moment to exit gracefully | ||
| sleep 1 | ||
| # Force-kill any stragglers | ||
| pkill -9 -f 'osgrep' 2>/dev/null || true | ||
| cleaned=true | ||
| fi |
There was a problem hiding this comment.
The use of 2>/dev/null and 2>&1 for blanket suppression of stderr violates the repository style guide (line 50) and general rules. Redirection of stdout (>/dev/null) is sufficient for pgrep to check for process existence without polluting the terminal. Additionally, using a more specific pattern for pkill -f (e.g., targeting the binary path or using word boundaries) is recommended to avoid accidentally matching the script's own path if it contains the string "osgrep".
| if pgrep -f 'osgrep' >/dev/null 2>&1; then | |
| print_info "Killing running osgrep processes..." | |
| pkill -f 'osgrep' 2>/dev/null || true | |
| # Give processes a moment to exit gracefully | |
| sleep 1 | |
| # Force-kill any stragglers | |
| pkill -9 -f 'osgrep' 2>/dev/null || true | |
| cleaned=true | |
| fi | |
| if pgrep -f 'osgrep' >/dev/null; then | |
| print_info "Killing running osgrep processes..." | |
| pkill -f 'osgrep' || true | |
| # Give processes a moment to exit gracefully | |
| sleep 1 | |
| # Force-kill any stragglers | |
| pkill -9 -f 'osgrep' || true | |
| cleaned=true | |
| fi |
References
- 2>/dev/null is acceptable ONLY when redirecting to log files, not blanket suppression. (link)
- In shell scripts, avoid blanket suppression of errors with '2>/dev/null'. For 'declare -f', redirecting only stdout ('>/dev/null') is sufficient as it does not output to stderr, allowing potential syntax errors to remain visible.
- Avoid using '2>/dev/null' for blanket suppression of command errors in shell scripts to ensure that authentication, syntax, or system issues remain visible for debugging.
- In shell scripts with
set -e, guardkillcommands within cleanup traps with|| trueto prevent premature termination if the target process has already exited, ensuring subsequent cleanup commands are executed.
1 participant
Summary
pkill -f osgrepas step 0 incleanup_osgrep()before removing binary/data~/.osgrep/is deletedFollowup to #2168 (v2.124.0 osgrep removal).