mirror of
https://github.com/empayre/fleet.git
synced 2024-11-06 17:05:18 +00:00
8fb22579ea
Closes: #12611 Changes: - Added three new documentation sections `/docs/get-started/`, `/docs/configuration` and `/docs/rest api/` - Updated folder names: `/docs/Using-Fleet/` » `/docs/Using Fleet` and `/docs/deploying` » `/docs/deploy/` - Moved `/docs/using-fleet/process-events.md` to `/articles` and updated the meta tags to change it into a guide. - Added support for a new meta tag: `navSection`. This meta tag is used to organize pages in the sidebar navigation on fleetdm.com/docs - Moved `docs/using-fleet/application-security.md` and `docs/using-fleet/security-audits.md` to the security handbook. - Moved `docs/deploying/load-testing.md` and `docs/deploying/debugging.md` to the engineering handbook. - Moved the following files/folders: - `docs/using-fleet/configuration-files/` » `docs/configuration/configuration-files/` - `docs/deploying/configuration.md` » `docs/configuration/fleet-server-configuration.md` - `docs/using-fleet/rest-api.md` » `docs/rest-api/rest-api.md` - `docs/using-fleet/monitoring-fleet.md` » `docs/deploy/rest-api.md` - Updated filenames: - `docs/using-fleet/permissions.md` » `docs/using-fleet/manage-access.md` - `docs/using-fleet/adding-hosts.md` » `docs/using-fleet/enroll-hosts.md` - `docs/using-fleet/teams.md` » `docs/using-fleet/segment-hosts.md` - `docs/using-fleet/fleet-ctl-agent-updates.md` » `docs/using-fleet/update-agents.md` - `docs/using-fleet/chromeos.md` » `docs/using-fleet/enroll-chromebooks.md` - Updated the generated markdown in `server/fleet/gen_activity_doc.go` and `server/service/osquery_utils/gen_queries_doc.go` - Updated the navigation sidebar and mobile dropdown links on docs pages to group pages by their `navSection` meta tag. - Updated fleetdm.com/docs not to show pages in the `docs/contributing/` folder in the sidebar navigation - Added redirects for docs pages that have moved. . --------- Co-authored-by: Mike Thomas <mthomas@fleetdm.com> Co-authored-by: Rachael Shaw <r@rachael.wtf>
30 lines
2.7 KiB
Markdown
30 lines
2.7 KiB
Markdown
# Osquery children processes
|
|
|
|
Osquery will run a watcher process to keep track of any child process and any managed extensions. What follows is a description of what happens during the watcher REPL and under what circumstances the child process and/or managed extensions are terminated.
|
|
|
|
As a first step, the watcher checks the state of the child worker process, which could be either `Alive` or `Non-existent`. If the process is `Alive`, we make sure the process is within its assigned resource quota, by checking:
|
|
|
|
1. That the maximum CPU utilization limit is not exceeded (which is controlled by osquery's `--watchdog_latency_limit` flag).
|
|
|
|
2. The maximum memory limit is not exceeded (which is controlled by osquery's `--watchdog_memory_limit` flag).
|
|
|
|
If the child process is within the resource limits, then it is deemed alive and well. Otherwise, we terminate the process by following these steps:
|
|
1. We send a `SIGUSR1` to the child process.
|
|
2. We send a `SIGTERM` to the child process.
|
|
3. After a delay (configured by osquery's `--watchdog_forced_shutdown_delay` flag) we send a `SIGKILL` to the child process.
|
|
|
|
If the child process is `Non-existent`, either because it didn't exist in the first place or because it was terminated, the watcher will try to spawn a new child process. But first, it will check whether the maximum number of allowed process re-spawns was reached. If it was, then the osquery process shutdowns.
|
|
|
|
After checking the state of the child worker, we check the state of every managed extension, which could be `Alive` or `Non-existent`.
|
|
|
|
If the managed extension is `Alive`, the watcher will check both the CPU utilization and memory consumption (the same checks we perform for the child process). If the managed extension is deemed unstable, we terminate the extension by following these steps:
|
|
1. We send a `SIGTERM` to the managed extension.
|
|
2. After a delay (configured by osquery's `--watchdog_forced_shutdown_delay` flag), we send a `SIGKILL` to the managed extension.
|
|
|
|
If the managed extension is `Non-existent` (either because it was `Non-existent` in the first place or because it was terminated due to resource contention), the watcher will try to 'launch' the managed extension. But first, it will check the respawn limit. If the respawn limit was reached or if for some reason the extension could be spawned, then the osquery process is shut down.
|
|
|
|
Lastly, we check the state of the watcher process itself. If it is deemed unhealthy because of resource contention, then the osquery process is shut down.
|
|
|
|
<meta name="pageOrderInSection" value="700">
|
|
<meta name="description" value="Learn about how osquery process manages child processes and managed extensions in Fleet.">
|
|
<meta name="navSection" value="Osquery management"> |