Title
#general
h

HarlanF

05/19/2022, 8:13 PM
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.
8:13 PM
I can't even say why this discovery query is running when
osqueryi
is started.
8:20 PM
If I run
sudo osqueryi --verbose
, I get this snippet:
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'
8:55 PM
Just the fact that a discovery query is being run when I launch
osqueryi
is itself pretty odd.
9:52 PM
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.
zwass

zwass

05/20/2022, 5:36 PM
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

HarlanF

05/24/2022, 7:15 PM
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?
7:15 PM
Also, if I put involve the socket from the running osqueryd, @zwass, in my call to osqueryi, that discovery query still comes up.
zwass

zwass

05/24/2022, 7:17 PM
Maybe osqueryi loads a config if it's available at the default path on the filesystem?
h

HarlanF

05/24/2022, 7:20 PM
I'm reasonably sure it would, but I wouldn't have expected the scheduling subsystem to be brought up.