Routinely get database error and my lists are missing from primary pihole

[jedis00]

What happened?

I routinely get a database error and my lists are missing from the primary pihole when I try to access the lists section or add a list. I have to run pihole -g in order to get it working again.

Expected Behaviour

Any ideas? This doesn't happen on the secondary pihole that is getting the synced config.

Nebula-sync Version

v0.11.0

Runtime

binary

Operating System

Debian 12

CPU Architecture

x86_64

Configuration

# /etc/default/nebula-sync

# —————————————————————————————————————————————
# Required Settings
# —————————————————————————————————————————————

# Primary Pi-hole (format: URL|API_PASSWORD)
# :contentReference[oaicite:0]{index=0}
PRIMARY="https://pihole1.myhost.net|asdasdasdas32432423"

# Comma-separated list of replicas (each: URL|API_PASSWORD)
# :contentReference[oaicite:1]{index=1}
REPLICAS="https://pihole2.myhost.net|asdasdasdas32432423"

# Perform a full Teleporter import/export? (true/false)
# :contentReference[oaicite:2]{index=2}
FULL_SYNC=true

# Run Pi-hole gravity after syncing? (true/false)
# :contentReference[oaicite:3]{index=3}
RUN_GRAVITY=true


# —————————————————————————————————————————————
# Optional Settings
# —————————————————————————————————————————————

# Cron schedule (standard cron syntax); if omitted, runs once at start
# :contentReference[oaicite:4]{index=4}
#CRON="0 * * * *"
CRON="*/5 * * * *"

# Timezone for cron and log timestamps
# :contentReference[oaicite:5]{index=5}
TZ="America/New_York"

# Skip TLS certificate verification? (true/false)
# :contentReference[oaicite:6]{index=6}
CLIENT_SKIP_TLS_VERIFICATION=false

# Seconds to wait between failed HTTP attempts
# :contentReference[oaicite:7]{index=7}
CLIENT_RETRY_DELAY_SECONDS=5

# HTTP client timeout, in seconds
# :contentReference[oaicite:8]{index=8}
CLIENT_TIMEOUT_SECONDS=30


# —————————————————————————————————————————————
# Selective-Sync Overrides (only if FULL_SYNC=false)
# ————————————————————————————————————————————
#SYNC_CONFIG_DNS=true
#SYNC_CONFIG_DHCP=true
#SYNC_CONFIG_RESOLVER=true
# … etc. see full list in docs :contentReference[oaicite:9]{index=9}


# —————————————————————————————————————————————
# Webhooks (optional)
# —————————————————————————————————————————————
# On success:
#WEBHOOK_SYNC_SUCCESS_URL="https://example.com/webhook-success"
# On failure:
#WEBHOOK_SYNC_FAILURE_URL="https://example.com/webhook-failure"
#METHOD, BODY and HEADERS support via WEBHOOK_SYNC_<OUTCOME>_{METHOD,BODY,HEADERS} :contentReference[oaicite:10]{index=10}

Relevant log output

Don't have any to share at the moment.

Pi-hole Version

Core v6.3FTL v6.4.1Web interface v6.4

[Sundancer78]

Hello, I have to chime in here, I'm having the same problem with nebula-sync version 0.11.0 on the primary Pi-Hole, Ubuntu 24.04.3 LTS, Runtime Binary, Configuration::

#sudo cat /etc/nebula-sync.env

Primary (pi-hole3 local)

PRIMARY=http://127.0.0.1|**********************

Replicas (pi-hole1 and pi-hole2)

REPLICAS=http://192.168.1.10|**********************,http://192.168.1.11|**********************

Optional / harmless

FULL_SYNC=true
RUN_GRAVITY=true

SYNC_CONFIG_DNS=true
SYNC_CONFIG_DHCP=false
SYNC_CONFIG_NTP=false
SYNC_CONFIG_RESOLVER=true
SYNC_CONFIG_DATABASE=true
SYNC_CONFIG_MISC=true
SYNC_CONFIG_DEBUG=false

SYNC_GRAVITY_GROUP=true
S YNC_GRAVITY_AD_LIST=true
SYNC_GRAVITY_AD_LIST_BY_GROUP=true
SYNC_GRAVITY_DOMAIN_LIST=true
SYNC_GRAVITY_DOMAIN_LIST_BY_GROUP=true

SYNC_GRAVITY_CLIENT=false
SYNC_GRAVITY_CLIENT_BY_GROUP=false
SYNC_GRAVITY_DHCP_LEASES=false

CRON=*/10 * * * *

Temporarily solved with:

• Briefly stop Pi-hole/FTL

#sudo systemctl stop pihole-FTL

• Create a backup of the broken database

#sudo mkdir -p /root/pihole-db-backup

#sudo cp -a /etc/pihole/gravity.db /root/pihole-db-#backup/gravity.db.broken.$(date +%F_%H%M%S)

#sudo ls -lah /root/pihole-db-backup/

• Rename the broken gravity.db file

#sudo mv /etc/pihole/gravity.db /etc/pihole/gravity.db.broken.$(date +%F_%H%M%S)

• Start Pi-hole and recreate Gravity

#sudo systemctl start pihole-FTL

#pihole -g

• Check if the database is OK is
  #sudo sqlite3 /etc/pihole/gravity.db "PRAGMA integrity_check;"

[dispo2]

Just replying to this as I am curious about several things.

Based on the above configs, you are running every 5 or 10 minutes with full sync AND gravity update.

Is that really best practice ?

Does it really need to be run every 5 minutes ?
Do you really need to pihole -g every time ?

(pihole -g forces a re-check/re-read of all adlists to see if they have changed, followed by a database rebuild. This is not only high impact on the pihole but it is also puts unnecessary load on the people who are creating free adlists for you to use. pihole -g also resets any caches so doing the above basically removes any ability for pihole to cache anything).

What are you trying to achieve here ? Synchronisation of whitelist/blacklist entries or updates to adlists that change rarely.
Do your whitelist/blacklist entries change that often ?

The corruption is happening on the master but does nebula write anything to the master or just the slaves ?
(If its read-only then I dont understand the source of the corruption).

I know everyone requirements are different but for comparison I run nebular-sync once a day with gravity update OFF, I let pihole deal with that when it wants or needs - which I think is once a week.
I have never once had any corruption on master or slaves.

[jedis00]

I look at it as, I am making an update for a reason. Usually to fix an issue, so I want the sync to be immediate on changes. Waiting 5 minutes isn't fast enough in some cases that I am manually putting the changes on the second pihole.

Nebulasync leaves the primary pihole in a broken state where the gui is broken, lists don't load, etc., until a pihole -g is ran on the primary. Those lists are coming from GitHub (I am using 6).

I am typically add local host entries or syncing an allow or deny list setting.

[dispo2]

The bit I cant get my head around is that you are getting corruption on the master.

I can imagine all sorts of scenarios where you get corruption on the slave, overloading the API, corruption of the updates being pushed by the sync etc etc

But I cant understand how a supposedly read-only process on the master can cause database / gui / corruption issues. The process being read-only on the master is totally an assumption on my part and I havent dug into the code so cant confirm either way.

Has SYNC_CONFIG_DEBUG thrown up anything ?

What hardware are you running this on ? You say deb12 on x86 so a virtual machine ?

I used to run pihole on arm micro-machines with SD cards so disk corruption might have been a possible source but if you aren't doing anything like that then disk is unlikely.