https://github.com/osquery/osquery logo
Join Slack
Powered by
Any tips for debugging why events tables are not b...
# kolide
t
Any tips for debugging why events tables are not being populated on certain Linux machines? For example, The 
socket_events
and 
process_events
tables are populated on half of our Linux machines running Kolide, but not the other. It sort of follows Linux distribution boundaries: • Ubuntu: Yes! • Fedora: No • Arch: Mixed • NixOS: Mixed. One machine has data in 
process_events
, the other doesn't. Both seem to only record 
systemd-timesyncd
bind calls in 
socket_events
One of the ones where none of the tables are populated is my personal machine, so I'm happy to investigate. Is it possible that the auditd rules installed by osquery could conflict with previously written configurations? I did check the output of 
sudo journalctl -t launcher
but it didn't seem to give any indications.
I'm happy to redirect the question to #general or through the official support channels, I just wasn't sure where to begin 🙂
s
Launcher isn’t doing anything special here — so whatever is up is going to be deeper in osquery. We can start here, though eventually you might need to land on another channel.
On linux, osquery has two different systems for events. There’s the older auditd framework, and the newer bpf one. IIRC the bpf one is only used on the tables who’s names start with bpf.
I know that auditd is a bit weird — I think linux only allows a single consumer of audit data. So I remember there’s some os level configs if you have multiple things that want that data. Might be info at https://osquery.readthedocs.io/en/latest/deployment/process-auditing
I don’t know if the bpf stuff makes more sense. We might need to add support for that in K2, not sure
4 Views
Open in Slack
PreviousNext
Powered by