New client not gracefully closed on error if it has grabbed the pipe/socket
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 433
- Forks
- 89
- PR merge metrics
- No merged PRs in 30d
Description
I've seen this issue occur on Windows when the osquery process is terminated. The osquery-go end of the named pipe is not released and any attempts to re-establish communication begins to fail with error due to the pipe not being available. This behaviour continues unless we Shutdown() the extension manager. This will not be necessary if we call serverClient.Close() when error is encountered due to osquery process being killed.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how the extension manager handles errors after the osquery process is killed and where serverClient is retained. Confirm the named pipe or socket remains unavailable without Shutdown(), then ensure the client is closed on that error path and verify that communication can be re-established afterward.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, operating-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100