Implement osqueryd health check #141
Labels
Comments
zwass
added a commit
that referenced
this issue
Oct 7, 2017
- Correctly detect when error channel is closed (potential fix for #134). Previously the logic was inverted for whether the channel was closed, so recovery was not initiated. Unit test TestOsqueryDies repros the suspected issue. - Allow logger to be set properly. - Add logging around recovery scenarios. - Check communication with both osquery and extension server in health check (previously only the extension server was checked). - Add healthcheck on interval that causes recovery on failure (Closes #141).
zwass
added a commit
that referenced
this issue
Oct 7, 2017
- Correctly detect when error channel is closed (potential fix for #134). Previously the logic was inverted for whether the channel was closed, so recovery was not initiated. Unit test TestOsqueryDies repros the suspected issue. - Allow logger to be set properly. - Add logging around recovery scenarios. - Check communication with both osquery and extension server in health check (previously only the extension server was checked). - Add healthcheck on interval that causes recovery on failure (Closes #141). - Do not set cmd output to ioutil.Discard. Causes a bug with cmd.Wait (see golang/go#20730)
zwass
added a commit
that referenced
this issue
Oct 12, 2017
- Correctly detect when error channel is closed (potential fix for #134). Previously the logic was inverted for whether the channel was closed, so recovery was not initiated. Unit test TestOsqueryDies repros the suspected issue. - Allow logger to be set properly. - Add logging around recovery scenarios. - Check communication with both osquery and extension server in health check (previously only the extension server was checked). - Add healthcheck on interval that causes recovery on failure (Closes #141). - Do not set cmd output to ioutil.Discard. Causes a bug with cmd.Wait (see golang/go#20730)
marpaia
pushed a commit
that referenced
this issue
Oct 17, 2017
- Changes to public API to better reflect actual usage and ease implementation. - Use errgroup for coordination of process management/cleanup. This helps prevent leaking of goroutines (relative to existing implementation). - Fix bug in which osquery process was not restarted after failure. - Allow logger to be set properly. - Add logging around recovery scenarios. - Check communication with both osquery and extension server in health check (previously only the extension server was checked). - Add healthcheck on interval that initiates recovery on failure (Closes #141). - Do not set cmd output to ioutil.Discard. Causes a bug with cmd.Wait (see golang/go#20730).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Perhaps by issuing a periodic
select 1to ensure that osqueryd is still responding to messages over the extension socket. If this fails, we could initiate a restart of osqueryd or the entire launcher.The text was updated successfully, but these errors were encountered: