After updating local DNS (added address), data is lost over +- 5 hours (dev branch)

Expected Behaviour:

Changes in local DNS settings do not cause loss of data

Actual Behaviour:

When adding new entry in local DNS, I lose data

(FYI, I am on the dev branch, latest version)

Debug Token:

Just checking, probably unrelated: Any other additions like custom web pages or third party plugins?

You have quite a few instances of failing query fetches:

*** [ DIAGNOSING ]: contents of /var/log/lighttpd

-rw-r--r-- 1 www-data www-data 4123 Nov 20 13:51 /var/log/lighttpd/error.log
   -----tail of error.log------
(gw_backend.c.2154) response already sent out, but backend returned error on socket: unix:/var/run/lighttpd/php.socket-0 for /admin/api_db.php?getAllQueries&from=1605342564.802&until=1605860964.802&types=1,2,3,4,5,6,7,8,9,10,11,12,13&_=1605860964544, terminating connection

Those could be related to unknown status values:

*** [ DIAGNOSING ]: contents of /var/log

-rw-r--r-- 1 pihole pihole 407995 Nov 20 13:49 /var/log/pihole-FTL.log
  -----tail of pihole-FTL.log------
   [2020-11-20 13:44:42.421 12938M] Error: Found unknown status 12 in long term database!
   [2020-11-20 13:44:42.421 12938M]        Timestamp: 1605858970
   [2020-11-20 13:44:42.421 12938M]        Continuing anyway...

Could well be prompted by status 12, which was introduced only recently.

To preclude you accidentally spoiled your database:
Did you perhaps experiment with the corresponding ftl fix/retries_master at some time in the past?

1 Like

No custom webpages, third party plugins or fix/retries_master as far as I'm aware. (only have pi-hole, unbound and log2ram on the pi zero)
I did try the ftl new/http and then reverted to dev. Did this potentially spoil the database?

Will read up on the status 12.

Any ideas on what I can do to fix this?

You probably could alter the offending values in your database by SQL.
I'll try to come up with the SQL statement and will provide it here.

But I'm reluctant to suggest that yet, as long as I haven't heard back from development, and not only because it probably would create false information: Your current state may be helpful to trace the root cause - if they confirm it's an issue.

Is it important for you to get that fixed asap, or could you do a bit longer with your current state?

I could do a bit longer with the current situation, as the overall functionality of the network does not seem (too) affected. Very curious to see what the team will find!

There is nothing you'd have to do here, it is FTL logging that there is something in the database it doesn't know how to handle. It will simply skip this query during import.

This can only happen when you use a more recent FTL version (or a deviated branch) in the past (which was aware of status 12) and then restart on another branch later (which isn not aware of status 12). It is impossible for FTL to store a query type it doesn't know about in the database. The very same logic would force it to skip saving said query (so it wouldn't be there on restart).

No, I assume the other way around. The branch development is aware of status 12. So it could have saved it into the database it. The new/http branch, however, likely wasn't aware of this at the time and may have thrown the warning. All in all, I wouldn't expect this to be the issue here.

When did you switch branches?

1 Like

I switched to back to dev (after new/http) on November 12th I think, the switch to new/https from dev was made about a week before I would estimate.

FYI, looking at recent logs, I see quite a few status 12 and 13 occurring.

They are not a problem at all (well, they may be but due to either your Internet connection or your specific client configuration because queries either never arrive or they arrive too slow). When you have recent dev branches everywhere, they should properly be shown as retired queries everywhere.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.