You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With unbound 1.11 being first release that switched away from libfstrm (#164, #264), we observe number of regressions with dnstap logging over unix socket.
This one is pretty obvious and relatively easy to reproduce:
* unbound running with dnstap logging enabled over unix socket, under some measurable load (few thousands+ requests per minute)
* dnstap process consuming the logs is restarted.
with 1.9.6, dnstap can reconnect to socket and process samples continuously
with 1.11.0, dnstap can reconnect to socket but receives only 99 samples, all stamped with ~time dnstap process was restarted. Next restart gets another 99 samples, and so on.
Restarting the unbound while leaving dnstap process to run mitigates the problem, until the next time dnstap is restarted.
Unbound's performance seems unaffected.
Doesn't happen when unbound is idle/lightly used.
We observe this on all our Unbound instances with 1.11, never happened on 1.9.6 or earlier versions we used before.
The text was updated successfully, but these errors were encountered:
With unbound 1.11 being first release that switched away from
libfstrm
(#164, #264), we observe number of regressions with dnstap logging over unix socket.This one is pretty obvious and relatively easy to reproduce:
Restarting the unbound while leaving dnstap process to run mitigates the problem, until the next time dnstap is restarted.
Unbound's performance seems unaffected.
Doesn't happen when unbound is idle/lightly used.
We observe this on all our Unbound instances with 1.11, never happened on 1.9.6 or earlier versions we used before.
The text was updated successfully, but these errors were encountered: