https://github.com/osquery/osquery logo
Join Slack
Powered by
Quite often I'm getting a discovery query fail bec...
# general
h
Quite often I'm getting a discovery query fail because it's using an extension we've built, complains there's no such table. In fact, it's consistently reproducible even using 
osqueryi
. Right when I enter osqueryi, I get the complaint, but I can go right to selecting something from the table in question, and it returns a row. Ideas? Thanks in advance.
I can't even say why this discovery query is running when 
osqueryi
is started.
If I run 
sudo osqueryi --verbose
, I get this snippet:
Copy code
I0519 22:16:36.517328 20271 init.cpp:357] osquery initialized [version=5.2.3]
I0519 22:16:36.517459 20271 extensions.cpp:438] Found autoloadable extension: <filename>
I0519 22:16:36.517486 20271 extensions.cpp:438] Found autoloadable extension: <filename>
I0519 22:16:36.517529 20271 extensions.cpp:438] Found autoloadable extension: <filename>
I0519 22:16:36.517552 20271 extensions.cpp:438] Found autoloadable extension: <filename>
I0519 22:16:36.517668 20271 dispatcher.cpp:78] Adding new service: WatcherRunner (0x55e348861ce8) to thread: 140014230087424 (0x55e348861fe0) in process 20271
I0519 22:16:36.518260 20272 watcher.cpp:708] Created and monitoring extension child (20274): <filename>
I0519 22:16:36.518278 20271 dispatcher.cpp:78] Adding new service: ExtensionWatcher (0x55e34885ed08) to thread: 140014221694720 (0x55e348859e50) in process 20271
I0519 22:16:36.518735 20272 watcher.cpp:708] Created and monitoring extension child (20275): <filename>
I0519 22:16:36.519155 20271 dispatcher.cpp:78] Adding new service: ExtensionRunnerCore (0x55e34885f888) to thread: 140014213302016 (0x55e3488607f0) in process 20271
I0519 22:16:36.519191 20276 interface.cpp:299] Extension manager service starting: /root/.osquery/shell.em
I0519 22:16:36.519171 20272 watcher.cpp:708] Created and monitoring extension child (20277): <filename>
I0519 22:16:36.519299 20271 auto_constructed_tables.cpp:99] Removing stale ATC entries
I0519 22:16:36.519623 20272 watcher.cpp:708] Created and monitoring extension child (20278): <filename>
W0519 22:16:36.586261 20271 packs.cpp:326] Discovery query failed (SELECT <...>): no such table: <extensionname>
I0519 22:16:36.586438 20271 events.cpp:70] Skipping subscriber: process_file_events: Subscriber disabled via configuration
Using a virtual database. Need help, type '.help'
Just the fact that a discovery query is being run when I launch 
osqueryi
is itself pretty odd.
I can shift the discovery query in that pack to any of the four extensions we've got, and 
osqueryi
will complain on startup that the discovery query failed. All four of those extensions work fine after that complaint. If the query's about a built-in table, no problem, no complaint on osqueryi's startup.
z
Do you have a config on the local filesystem that osquery is loading from the default location that has the discovery query in it?
h
Yes, there are 5 query packs, 1 of which has that discovery query in it. But why would running 
osqueryi
involve any of those packs?
Also, if I put involve the socket from the running osqueryd, @zwass, in my call to osqueryi, that discovery query still comes up.
z
Maybe osqueryi loads a config if it's available at the default path on the filesystem?
h
I'm reasonably sure it would, but I wouldn't have expected the scheduling subsystem to be brought up.
39 Views
Open in Slack
PreviousNext
Powered by