With my memory management a little less impeachable, we turn now to different behavior on different OSes.

On OmniOS, in Vultr's network, my A and AAAA lookups check in (skadns_t *)->list after skadns_update(...), with failure, quickly. On HardenedBSD, in Shaw's network (so I'm aware that I'm not controlling for different DNS recursors here, and I should be), my A and AAAA lookups check with failure after the 45 seconds.

I link truss -f of my application piped through grep skadns' PID to show only skadns, on OmniOS <https://umbrellix.net/~ellenor/omnios.sdtruss.txt> and HardenedBSD <https://umbrellix.net/~ellenor/hbsd.sdtruss.txt>. If my application's truss output is required, I can supply that too.

On 10/7/22 08:27, Ellenor Bjornsdottir wrote:
While chasing this bug, I found out that I screwed up memory management in my 

This is no longer skaware@'s problem. I'll be back with a truss run once I've 
fixed /that/.

On 6 October 2022 16:45:50 UTC, Laurent Bercot<ska-skaw...@skarnet.org>  wrote:
Neither of those conditions actually apply - my network is up and my resolver 
is responding (albeit slowly - it takes about a second). I get the expected 
response on the first batch of queries I fire off, but then the second batch 
gets ENETUNREACH. This happens every time I run my program (albeit on special 
snowflake illumos; I have not tried on other OSes).
If you think s6-dns is behaving incorrectly, please pastebin a strace
(or local equivalent) of skadnsd somewhere, so we can check what it is


Amelia Bjornsdottir (she, they)
sysadmin umbrellix.net, deputy sysadmin chatspeed.net
jabber: eamon.aka.amy.malik ~on~ umbrellix.net

Reply via email to