https://github.com/osquery/osquery logo
Join SlackCommunities
Powered by
Hi all, we are working on creating custom plugins ...
# golang
z
Hi all, we are working on creating custom plugins (currently loggers and tables) that we would like to run from an existing background daemon we have (instead of autoloading a 
.ext
binary). We have successfully managed to get the plugins to communicate with 
osqueryd
using 
extensions_require
and not specifying the 
extensions_autoload
flag. However, we have noticed that before 
osqueryd
sets up the scheduler, it still waits the 
extensions_timeout
interval and then prints that it was unable to load the required extension (however, it does not crash because it was registered via connection to the socket from our process). Is there a way to disable the autoload behavior and only attempt to connect the plugins from the extension manager creation?
s
mmm, we do something similar in Kolide’s agent, and I’m not sure we’ve seen exactly that issue. When you start osquery, when does your existing background daemon try to register it’s extensions and how does that work? Because I wonder if it’s not working
The 
extensions_require
option is how you tell osquery to wait for an extension to load. It says nothing about where the extension should be loaded from, It pauses startup for that extension to load. This is critical if you need some extension for config/logs/enrollment. You’d need to pause osquery for the extension to load. This is especially true if you have an external daemon trying to register extensions over the socket
z
Yes that makes sense to me, but the behavior we see is the following: • 
--extensions_require=logger_plugin_id
• 
--extensions_timeout=20
• 
--extensions_interval=2
• 
--logger_plugin=logger_plugin_id
Status logs soon after startup:
Copy code
Extension manager service starting: /var/osquery/osquery.em
Registering extension (plugin_manager_id, 39582, version=, sdk=)
Extension 39582 registered logger plugin logger_plugin_id
Then after 20 seconds/the 
extensions_timeout
time, we see the following message:
Copy code
Required extension not found or not loaded: logger_plugin_id
But 
osquery
continues to initialize after that point instead of crashing and runs scheduled queries and everything as expected.
To directly answer your question about when the background agent registers the extensions, it starts 
osquery
manually and then immediately attempts to register the extensions which appears to be successful based on the log output above.
s
I’m not sure. I wonder if there’s a race somewhere. What happens if you stick a sleep in btween starting osquery and registering the extension?
FWIW I don’t think this is related to go. I don’t think we see this in launcher, but I forget if we did something to mitagate it. But osquery does have bugs
z
Sleeping in between seems to give the same behavior. I think you're right that this is probably osquery and not go, I'll ask in general. Appreciate the help!
s
It’s interesting that I don’t tyhink I see this in launcher,
I wonder if you can make a much simpler test case. Like, start osquery on the command line, and make a simpler extension to execute
z
Yeah I've started looking at launcher to see if you do anything different then us during startup. I'll also try and create a simple test case.
s
Launcher’s startup code is pretty gnarly. Mostly, it’s old and a lot has been added.
But I think making an isolated test case will probably help find the issue fastest
2 Views
Open in Slack
PreviousNext
Powered by