Yes, we haven't changed anything in this regard.
Does this also happen without the external script (even when it worked before)?
I'm asking because we have not changed anything database-related in v5.5(.1) compared to v5.4:
Checking https://github.com/pi-hole/FTL/compare/release/v5.4...release/v5.5 we see that the only changes are:
- Various commits caused by the
dnsmasqupdate - Fix for Query Log filtering and memory optimizations by DL6ER · Pull Request #1032 · pi-hole/FTL · GitHub
- Config option MAXDBDAYS fixes and tweaks by DL6ER · Pull Request #1033 · pi-hole/FTL · GitHub
edit I just verified with grep -c "Database is busy" /var/log/pihole-FTL.log that I don't see this message myself. I also tested the log files of two friends where I have VPN/SSH access to and there aren't any errors either (I updated them already as well).
Running the grep -c "Database is busy" /var/log/pihole-FTL.log command, I get
63
as a result.
Running on dev btw.
Sorry for the delay.
I checked my entire group management configuration, which is why I do the SQLITE3 inserts in the first place, everything appears to be OK, all entries appear to be OK.
Two questions:
- If such an error (ERROR: Gravity database not available) is logged, does FTL retry, thus succeeding the second time?
- is it possible this is caused by using sqlIte3 (version 3.27.2 2019-02-25 16:06:06), as opposed to pihole-FTL sqlite3 (version 3.34.0 2020-12-01 16:14:00)? I haven't gotten around to changing my scripts...
I got
pi@raspberrypi:/var/log $ grep -c "Database is busy" /var/log/pihole-FTL.log => 19
as per @DL6ER - he stated that it is normal behavior, as my best guess this happens when pihole is starting (DB) while requests coming from your NW devices .... correct me if I am wrong ....
But seems to be an error as you stated you checked log files on other devices and u haven't found any entries like these .....
No, it uses a fallback to not delay your queries:
However, it will try again on the next occasion.
No, exposing an interface to SQLite3 embedded in FTL is nothing else than a convenience feature (user won't have to install sqlite3 as extra package). There is nothing else in this and no transition is needed. The main driver for this was the new command UPDATE FROM:
UPDATE-FROM is supported beginning in SQLite version 3.33.0 (2020-08-14)
It's take a long time until we could use it in our scripts and we'd always have to add fallback in case users still run this Pi-holes on stretch, etc. which will likely never receive this update.
can this:
[2021-01-19 16:16:33.850 16793M] domain_in_list("detectportal.firefox.com", 0x73228aa8, whitelist): Database is busy, assuming domain is NOT on list
[2021-01-19 16:16:33.851 16793M] domain_in_list("detectportal.firefox.com", 0x73229408, blacklist): Database is busy, assuming domain is NOT on list
[2021-01-19 16:16:33.851 16793M] domain_in_list("detectportal.firefox.com", 0x73228148, gravity): Database is busy, assuming domain is NOT on list
then be considered as an error which needs to be fixed by development or works as designed?
It depends. Are you using tools to access the database (also like the long-term tool on the dashboard)?
If yes, then this is expected. If not, then we'd have to find out why your database is busy:
- Do these messages also show up after restarting
pihole-FTL? - Do these messages also show up after restarting the device?
(hopefully terminating any possible third-party) - Does
sudo -u pihole sqlite3 /etc/pihole/gravity.db "BEGIN EXCLUSIVE;COMMIT"work or does it complain about a database lock/busy as well? If so, does it do the same when you stoppihole-FTLand try this again?
sudo -u pihole sqlite3 /etc/pihole/gravity.db "BEGIN EXCLUSIVE;COMMIT"
gives no reaction on the command prompt, any other place to check for an expected result? - where to check and what should the command do?
the db busy are not showing up during normal op, mainly while doing pihole upgrades or restarts
not showing up if I restart DNS resolver via brower nor showing up while rebooting pi itself
Okay, that is expected, sorry I should have said that. This command locks the database exclusively and releases the lock immediately. It would have only complained if the database would have been in a busy state.
This may mean that your CPU is a lot faster than your disk and that the (intended) concurrency of FTL hits a few mutiple-access-at-once spots during startup. This is not a problem as FTL expects such things and handles them (hence, the log message saying what it did).
overlapp while I replied 
pls see my findings in my post before u replied
might also happen while doing a gravity db update, I'll test right now
tested that yesterday (pihole -g), errors do NOT appear in this case
pihole -g is working fine ... no errors, so seems to be an "update issue" while performing pihole -up,
so can u confirm that the "error" can be safetly igored? I guess there will be no development required in that case ...?
Also with a new install!!!
Yes, the error can be safely ignored. I will nevertheless keep an eye open and fix anything odd I encounter. Pi-hole v6.0 development is in full swing and it'll do a few things differently. We'll have an extended beta period before any release and maybe the two of you would enjoy participating.
1 Like
Thanks for the confirmation.
And yes, definitly, thanks for offering. Let me know if anything I can help with
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.