Changing ownership of the log directory to dnslog:nofiles fixed the problem.ĭrwxr-sr-x 2 dnslog nofiles 4096 Mar 19 03:18 main As multilog never really started, tinydns locked up after pumping enough data into the log pipe which apparently filled up its input buffer (guess I could find out exactly how large it is.). Logging in djbdns is implemented with a FIFO pipe between tinydns and the logger process - usually multilog. To make a long story short, turns out that daemontools - a support package that monitors djbdns services - was firing up multilog which in turn was failing to run due to invalid permissions set in its log directory (multilog was executed under dnslog:nofiles and its log directory was owned by root:root, so there was little chance of multilog writing files there). I was not happy.Īfter chasing this bug for a ridiculous amount of time, which included a fair bit of strace, tcpdump, reboots, googling, scripting tests, comparing it with a working installation, etc, I got to the bottom of it. A reboot would give me another allowance of ~250 queries. After resolving around 250 remote queries, tinydns just stopped responding with no error messages. Recently I came across an issue in the djbdns service on a linux host that I am setting up.
