Could it be something network related? Like the ho...
# general
Could it be something network related? Like the host not able to communicate with the server so it just stops trying?
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
I am running
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
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
Running on windows... I'll try running with
and see if that helps
Also, where am I supposed to see the tls dump? I enabled it and I can't find it
I enable
via CLI when debugging.
sudo /usr/bin/osqueryd --flagfile [...] --config_path [...] --verbose --tls_dump
how can you run
with all the
Failed to open handle to process <num> with 5
coming up all the time?
I wonder if the following PR fixes your issue:
no, you will still see some of those log lines for protected processes
can be ignored... eventually we should clean those up.