Open 0xpaulbenoit opened 4 years ago
In our code, we do similar.
launcher itself use a rate limiter and retry logic (embarassingly we have two different rate limiter implementations)
Our extension, which as no content, but is there to keep the socket open, uses a simple sleep. launcher-extension.go
I'm not sure this is a bug, per se, but how windows is. I'm not sure that the sleep and retry belongs in the sdk. Feels like it might be better to keep it in the callers. But I'm interested in discussing that
I think osquery-go should try to make it as easy as possible for users to get extensions connected up to osquery. If this kind of retry logic is a necessary (or even often necessary) part of connecting on Windows, I'd argue that it deserves inclusion directly.
I think osquery-go should try to make it as easy as possible for users to get extensions connected up to osquery. If this kind of retry logic is a necessary (or even often necessary) part of connecting on Windows, I'd argue that it deserves inclusion directly.
I think I agree, though we should probably understand if this is a bug in osquery first.
Context
osquery 4.2
Windows 10 Pro 64bit
Test extension
Running the above test extension with
.\osqueryi.exe --allow_unsafe --extension=.\extension.exe
will throw an errorregistering extension: i/o timeout
. Then about a minute later the extension will connect successfully.Adding a
time.Sleep(1 * time.Second)
to the beginning of the extension will make it connect on the first try instead.Similar behavior happens when the extension is run via the extensions.load file.