Updating pihole-cloudsync for Beta 5

I've upgraded a Pi-hole VM to Beta 5 and am now want to update my pihole-cloudsync script to work with the updated gravity.db approach to storing Pi-hole's info.

The original version of my script copied all the relevant files (whitelist, blacklist, adlist, regex) from /etc/pihole to a local private git repo called my-pihole-lists before doing its comparisons and synching. I didn't bother stopping stopping the pihole-FTL service in the original script while copying the files (the script runs pihole -g when complete to pick up the updates). But with the updated version of the script I'm working on today, I'm wondering whether I need to stop the pihole-FTL process while copying the gravity.db file into or out of the /etc/pihole directory. Is that worth doing? It would mean the Pi-hole in question wouldn't resolve DNS requests for however long it took for the file operation to complete, so I'd rather not mess with it if it's not necessary to do so. Thanks for any insights!

1 Like

If you are copying the file, you should not need to stop FTL.

When you replace the file, I would stop FTL, put the file in place and then start FTL.

Thanks. I'll do it that way. :slight_smile:

Follow-up: Is the "stop, write new gravity.db, start" only so that Pi-hole will pick up the changes? My script runs pihole -g when finished to handle that.

But if you're recommending to avoid file write errors (I don't know what else might be trying to write to gravity.db), then I will definitely do it your way.

I am not the FTL developer, but if you stop FTL from using that file while you replace it, that appears to be a conservative approach.

Updated version (4.0) of pihole-cloudsync with support for gravity.db & Beta 5 is pushed:

2 Likes