https://github.com/osquery/osquery logo
Title
a

AoS

10/28/2019, 2:06 PM
Could it be something network related? Like the host not able to communicate with the server so it just stops trying?
p

packetzero

10/28/2019, 2:51 PM
You have to definitively determine where the blockage is. Run with --verbose=1 flag and see if the scheduler is still running queries. Add --tls_dump=1 flag to see that http communication is still continuing. Also, note that osquery only sends differential results by default, so if there is no change from previous results, no results are sent. So perhaps add something to your schedule that runs every minute or so that has diffs like
SELECT total_seconds FROM uptime
a

AoS

10/28/2019, 3:01 PM
I am running
--vebose
on all my hosts and nothing seems out of the ordinary. Also there is no need for me to use test queries because I am judging whether a host is communicating is with Kolide's last seen on each host
This way I know for sure that the host has stopped communicating
j

Jams

10/28/2019, 3:25 PM
Abrupt changes to osqueryd workers could be a result of watcher.cpp. Thus, the watcher daemon could have stopped the process if memory or cpu utilization reached threshold.
Also, try
sudo journalctl -u osqueryd
a

AoS

10/28/2019, 3:34 PM
Running on windows... I'll try running with
--disable_watchdog
and see if that helps
Also, where am I supposed to see the tls dump? I enabled it and I can't find it
j

Jams

10/28/2019, 3:42 PM
I enable
tls_dump
via CLI when debugging.
sudo /usr/bin/osqueryd --flagfile [...] --config_path [...] --verbose --tls_dump
a

AoS

10/29/2019, 8:17 AM
how can you run
--verbose
with all the
Failed to open handle to process <num> with 5
coming up all the time?
j

Jams

10/29/2019, 5:09 PM
I wonder if the following PR fixes your issue: https://github.com/osquery/osquery/pull/5919/files
p

packetzero

10/29/2019, 5:12 PM
no, you will still see some of those log lines for protected processes
can be ignored... eventually we should clean those up.