Jerome Gravel-Niquet

This is an old issue, but I'm also facing this using containerd 1.4.1 on linux with the devmapper snapshotter: ``` time="2020-12-08T12:20:48.474220424Z" level=debug msg="prepare snapshot" key="extract-474123271-H6yu sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a" parent= time="2020-12-08T12:20:48.474668519Z" level=debug msg=prepare...

@fuweid hmm, unfortunately I've had to wipe the state on this server and start over to get that capacity back. If it happens again, I'll try to procure these files....

I've often landed on that issue throughout my searches. However, our woes seemed to happen out of nowhere. Maybe after a containerd restart? Or maybe when we deployed our orchestration...

That's a great question. Schema synchronization has been largely left to users. At Fly: We have a repository containing Corrosion-related configuration that we deploy independently. Usually this is a multi-step...

I did! Well, I used `ResolvConf::default()` which finalizes. Then I added my servers and changed a few options. That's a common pattern in Rust. Perhaps it would be better to...

Yes. Initially I thought I wasn't running with the proper `RUST_BACKTRACE` env vars and didn't bother to look for it, but we actually are! ``` thread 'main' panicked at 'attempt...

This appears to happen repeatedly during the same execution. I'm assuming it can get in a bad state and stay that way.

Ah! Maybe this is related them: I have 2 stub resolvers, one for UDP and one for TCP. I'm forwarding queries and I want to keep the same protocol as...

Thank you! Anything I can do in the meantime? I deployed our server to more hosts and this seems to happen quite a bit. Restarting the server seems to be...

Thanks! For now I've forked this repo and make `Query::run_query` public. Using that instead of `run` shouldn't use the `next_server` function.