Query Log "Unknown" entry

[DL6ER]

In raising this issue, I confirm the following (please check boxes, eg [X]) Failure to fill the template will close your issue:

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated
• The issue I am reporting isn't a duplicate

How familiar are you with the codebase?:

10

---

[BUG | ISSUE] Expected Behaviour:

git-lfs.github.com query log entry listed as OK

[BUG | ISSUE] Actual Behaviour:

git-lfs.github.com query log entry listed as Unknown but this does not seem to be reproducible

Interestingly, the Unknown status is gone after restarting FTL, so I assume FTL wasn't able to find it in pihole.log due to a yet unknown reason.

pihole.log excerpt

Jun 23 17:04:42 dnsmasq[20193]: query[A] git-lfs.github.com from 127.0.0.1
Jun 23 17:04:42 dnsmasq[20193]: forwarded git-lfs.github.com to 2001:1608:10:25::1c04:b12f
Jun 23 17:04:42 dnsmasq[20193]: reply git-lfs.github.com is <CNAME>
Jun 23 17:04:42 dnsmasq[20193]: reply github.map.fastly.net is 151.101.112.133

[DL6ER]

Possible solution: Wait longer than 100 milliseconds in parser.c#L400

[tording]

I am having this same issue. Requests showing up as unknown in the query log but the requests are actually working, just showing unknown. Where is this file that I change the wait to longer than 100 milliseconds?

[AzureMarker]

There is a log snippet available here: https://discourse.pi-hole.net/t/query-log-status-unknown-but-query-works-and-pihole-responds/4095

[DL6ER]

@tording Does this go away if you restart pihole-FTL? The line I posted in my comment above is the place where you would have to change it. However, you'd have to compile FTL locally. I'm still looking into a more elegant solution.

[DL6ER]

Unfortunately, this seems to be an expected issue on systems that are either very slow or under heavy load. It is caused by dnsmasq's async logging. I found no really elegant solution to this that would not affect the performance of FTL in a notable way (as we would have to wait on dnsmasq's output that is delayed in these cases).

Restarting FTL will always resolve this problem when re-parsing the log file.

Feel free to re-open once you find an elegant solution to this issue.