I'm having issues with /tmp/osquery_results and /t...
# fleet
t
I'm having issues with /tmp/osquery_results and /tmp/osquery_status logs being written to, even opening them wide open (777 root:root) after running the fleet.service as root when applying this guidance to a RHEL9 server https://fleetdm.com/docs/deploy/deploy-fleet-on-centos SO I took a different approach with https://www.redhat.com/sysadmin/fleetdm-get-started. Same issue, Fleet works great, but the /tmp/osquery_results and /tmp/osquery_status in the containers aren't being written too either. Anyone seen this?
k
Hi @Tom Wilburn! Are you seeing any errors in the Fleet server logs?
t
Not seeing fleet logs.
That’s the issue
k
The Fleet server logs would be written to stdout/stderr by default. The osquery status and results logs are where the associated logs returned from your hosts are stored.
t
Everything works fine except /tmp/osquery_results and /tmp/osquery_status
k
Do you have hosts enrolled?
t
One
On that second link, I added variables to write to /opt/fleet instead
Same result
k
Good deal. In that case, we'd at least expect to see some osquery status logs, even if you don't have any scheduled queries set up. Checking the Fleet server logs might give us a clue as to why you don't
t
The logs are created, but not being written to
Size 0
Agent reporting
Queries ran
Apologies
Driving
Permissions matching a known good on CentOs7
k
Fleet itself doesn't write the server logs to file. Those go to stderr and stdout. In kubernetes, those would be in the pod logs
t
Problem is CentOS7 is reaching EOL
k
I'm hoping that those will give us a clue as to why nothing is being written to the osquery log files.
t
I have one install via Docker
k
Okay. in Docker, Those log to the container's logs.
t
On another server, using Centos7 install guidance on fleet.com
Yes, but those weren’t being written to either
So I added to the docker-compose.yml to write to opt/fleet instead
Same, files created, but not being written too
I’m going to try a Rhel 8 when I get back to desk
This is 4.43.3 and then 4.44.0
k
Before you try a new setup, I'd like to take a look at the docker-compose file you're using.
t
Cut-paste from the link at the beginning of this thread
k
Okay. in that case, the logs I'm talking about now (the Fleet server logs) would not be written to a file.
t
Yeah, the ones of concern to me is the osquery_result
Status
k
There are multiple types of logs at play: 1. The Fleet server logs - Those would be in stdout/stderr 2. The osquery_results logs - Those should write to file, but aren't 3. The osquery_status logs - Those should write to file, but aren't
t
When I restart the service I see output that usually goes to status
Exactly
k
What I'd like to see is the Fleet server logs themselves. Those may have errors that would shed light.
It does sound like you're seeing some action in the status logs, so that is a good sign.
Do you have any scheduled queries set up in Fleet?
Those would be saved queries with an interval set and automations turned on.
Like the first one here:
t
I don’t have scheduled queries up on either, but I have ran queries, turned on/off agents, deleted agents, reinstalled agents, etc and nothing is writing. When I get back to my office I will set a scheduled query
The working CentOs fleet my primary that has scheduled queries running fine. I see the output in results
That definitely solves for half the issue, results, hopefully
For the osquery_status, I believe I should have seen some things write (agent connections at least) but no joy
k
Got it. I definitely wouldn't expect anything in osquery_results.
t
The fear is the problem with status may cause an issue with results. Will confirm hopefully in an hour
You’re definitely steering me the right way. Very appreciative
k
Brilliant. I'll be around then.