How to test if database is locked?

Since yesterday on 5.0 and I have the impression something is wrong. I went from database 11 to 12 and on import the number of domains do not change anymore even if a list is not dowloaded and there is no previous file.

I added a domain to blacklist to test and it is blocked. In queries I press the whitelist button and I get the message that is done. However nothing was done.

When importing with pihole -g -o I get the message that the database is locked and I have that impression too and that is why how to determine if the database is indeed locked?

Try

lsof /etc/pihole/gravity.db

What are you importing with this command? This is the command to optimize the database.

Output:

pihole-FT 1639 pihole   12r   REG  179,2 13030400 63883 /etc/pihole/gravity.db

12r indicates that it is read only and it should be u if it was read and write?

That is correct and on the first run the number of domains is larger than on the second run so I do a manual pihole -g -o to end up with at smaller size of the database.

Edit:

After many times running pihole -g -o it's result are random and I still don't know if the database is locked or not for real.

The database seems to cleaning itself so if the old -o is still effective or that is running in a asymmetric problem that one task is still running and while next is started.

Hmmm that is strange because I can enforce a optimize despite a "r" is present and maybe that is displayed now Pi-hole is swapping database after building the new domains list.

  [â] Cleaning up stray matter
  [â] Optimizing domains database

  [â] DNS service is running
  [â] Pi-hole blocking is Enabled
root@raspberrypi:/etc/pihole# lsof /etc/pihole/gravity.db
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pihole-FT 4740 root   15r   REG  179,2  5126144  720 /etc/pihole/gravity.db

So the problem standing is that whitelisting in queries is not working despite the message that it is added to the whitelist.

Trying a fresh install and an old error is still there. User pihole is not created after a uninstall. I think because the group pihole is not removed. This an ancient error.

[i] Downloading and Installing FTL...transferred... chown: invalid user: âpihole:piholeâ
  [â] Downloading and Installing FTL
  [â] Installing scripts from /etc/.pihole

  [i] Installing configs from /etc/.pihole...
  [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [â] Copying 01-pihole.conf to /etc/dnsmasq.d/01-pihole.conf
  Error: Unable to initialize configuration file /etc/pihole/pihole-FTL.conf
  [â] Failure in dependent config copy function.
grep: /etc/pihole/setupVars.conf: No such file or directory
  [i] Testing if systemd-resolved is enabled
  [i] Systemd-resolved is not enabled
  [i] Restarting services...
  [â] Enabling pihole-FTL service to start on reboot...
  [â] Restarting pihole-FTL service...
  Installation Failure: /etc/pihole/setupVars.conf does not exist!
  Please run 'pihole -r', and choose the 'reconfigure' option to fix.

Update: after removing the group an repeat install went as a breeze.

I looked it up and I reported this in September 2019 to DL6ER when beta testing.

So, during the uninstall the Group pihole is not removed and on re-install it bites back.
Manual remove of the Group and running basic_install.sh worked then without a hitch.

We've been waiting for your PR.

And you are walking that road now many times and you know that is not going to happen!

You can not.


As you observed, FTL uses a continous connection to the database. However, it should not be locking the database. In fact, it cannot.

Proof: We open the connection with SQLITE_OPEN_READONLY.

So, whatever is causing a lock on gravity.db must come from somewhere else.

We're all here to help, however, I've not seen

You can very well remind me of such things when you see I forgot about them. Only during the beta I wrote almost 1000 replies to users, many were quite long. Things get forgotten. They can still get fixed, for the next version, then.

The uninstall script is something I have never used myself. And it is something I will likely never use. However, we can still fix it if necessary.

Thanks DL6ER and I assume that is a asymmetric problem as I added that to my earlier posting. I can do multiple runs where it is not locked and then suddenly it is displaying locked. It stays locked forever then. It are the same lists and nothing is added or removed in web interface or the CLI.

I just made two new test runs and it was still locked. To unlock I can run pihole -g -r and then Teleport in and new pihole -g -o .

Or go to my adlist and disable all but one and run again then it the database is unlocked again. Enabling the different list again displays locked again.

Next test will be to test with each separate list to see if a list itself is the problem.

It would be nice that the group not being removed is fixed because it not being able to reinstall Pi-hole without manual removal of the group is not a small thing.