Hi osquery team, does osquery generate any process...
# general
w
Hi osquery team, does osquery generate any processes in any case?
j
AFAIK osquery runs entirely in a single process and doesn't spawn new ones.
s
It depends; in daemon mode osquery starts as the watchdog process, then forks and proceeds as the worker process. Then the worker might fork again, on Linux only, if you’re querying tables that support the
pid_with_namespace
constraint (which makes the table run inside the specified namespace; this is for querying containers).
But otherwise osquery never executes other binaries; if that happens is a bug and should be fixed.
w
could u explain "Then the worker might fork again, on Linux only"? when it would fork?
s
as I mentioned “if you’re querying tables that support the
pid_with_namespace
constraint”
namely, the file table supports this, so when doing a query like
select * from file where path = <path> AND pid_with_namespace = <pid in container>
a fork will be created, because for osquery to be able to switch namespace and access the container filesystem, it has to be a process with only 1 thread and the main worker potentially has multiple threads.
w
a fork means one independent process?
and for each run of query would spawn one process?
s
It’s a new process but it’s a child of the osquery worker, so the process of the binary is always osqueryd
w
ok, there might be multiple processes with "osqueryd" running simultaneously?
s
technically it’s every time the table logic is hit.. unfortunately.. so a JOIN might cause a fork being executed and terminated at every row of the first table being joined
“there might be multiple processes with “osqueryd” running simultaneously” correct. There are always at least 2 when you run osquery as a daemon, provided you keep the watchdog enabled, otherwise if you run with
--disable_watchdog=true
, then there will be only one process, the worker itself.
w
but whatever how many processes it would spawns, they are all restricted with mem by watch dog settings, right?
s
I forgot another case, which actually enters in the “osquery runs a different binary than itself”, I was totally forgetting extensions! That been said, the watchdog monitors the worker and the extensions (if instructed). But there’s a shortcoming currently with the forked process created by the container support I was talking about; that is not tracked by the watchdog, because there’s currently no way of letting the watchdog know of that process existence.
w
but the spawn process is for running queries, right? if there is no way to control the resource it consume, will it cause potential problem?
s
Yes the spawned process is to execute the table logic that is triggered by the query. And yes, it can.
w
ok, do you have plan in the future, osquery could change this situation and fix it?
s
There’s no current plan I’m aware of. There has been talk in the past about adding communication between the watchdog and the worker, but it’s not an easy task, also because there are other interests around it, so it can’t be a one off.