q-feeds-connector: "error in configd communication" every update when the Unbound DNSBL rebuild takes longer than 120s

Aperta Adatta ai principianti
  • Qualcosa non va?
#5,923 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
cli, linux, python
Ambito
devtools, networking

Direzione di ricerca

La chiamata che fallisce è subprocess.run di configctl in security/q-feeds-connector/src/opnsense/scripts/qfeeds/lib/init.py, all'interno di QFeedsActions.unbound_load. Leggila insieme al guard flock in scripts/unbound/blocklists.py per confermare che le esecuzioni concorrenti restano bloccate. La correzione consiste nell'aggiungere il flag -d a quella chiamata a configctl. Il lavoro è completato quando non viene registrato alcun errore di configd dopo una ricostruzione DNSBL riuscita che dura più di 120 secondi; il segnalatore l'ha testato manualmente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Important notices

  • I have read the contributing guide lines
  • I have searched the existing issues, open and closed, and I'm convinced that mine is new.
  • The title contains the plugin to which this issue belongs

Describe the bug

QFeedsActions.unbound_load() triggers the Unbound blocklist rebuild synchronously:

# security/q-feeds-connector/src/opnsense/scripts/qfeeds/lib/__init__.py (master, line 185)
subprocess.run(['/usr/local/sbin/configctl', 'unbound', 'dnsbl'])

configctl uses a fixed socket timeout of 120 seconds (socket.setdefaulttimeout(120) in configd_ctl.py). With larger blocklists the unbound dnsbl action takes longer than that. configctl then gives up and prints error in configd communication, see syslog for details to stderr. configd logs this as an error of the qfeeds update action. The DNSBL update itself keeps running in the background and finishes successfully, so the error is a false alarm.

To Reproduce

  1. Enable Q-Feeds domain feeds together with a large Unbound DNSBL configuration (here: ~11.3 million entries, parsing takes 100–140s).
  2. Wait for the scheduled qfeeds update that results in an unbound_load.
  3. See /var/log/configd/latest.log.

Log excerpt (configd):

09:05:00 [22960eda-...] update QFeeds
09:07:43 [cf77059e-...] Updating Unbound DNSBLs
09:09:44 [22960eda-...] Script action stderr returned "b'error in configd communication, see syslog for details'"

Resolver log of the same run: blocklist parsing done in 135.16 seconds (11329394 records) at 09:09:58, then blocklist loaded.

System log (configctl):

error in configd communication  Traceback (most recent call last):
  File "/usr/local/sbin/configctl", line 66, in exec_config_cmd
    line = sock.recv(65536).decode()
TimeoutError: timed out

This happens on every update with changed feeds (here every 4 hours).

Manual reproduction, same command as the plugin uses:

# time configctl unbound dnsbl
-> returns after 121s, stderr: "error in configd communication, see syslog for details"
   (resolver: "blocklist parsing done in 125.96 seconds", then "blocklist loaded")

Expected behavior

No error is logged when the DNSBL update succeeds.

Proposed fix

Detach the call, the same way the default cron job does (configctl -d -- unbound dnsbl):

-            subprocess.run(['/usr/local/sbin/configctl', 'unbound', 'dnsbl'])
+            subprocess.run(['/usr/local/sbin/configctl', '-d', 'unbound', 'dnsbl'])

Tested:

# time configctl -d unbound dnsbl
-> returns after 0s with the job id; configd: "[unbound dnsbl] returned OK" after ~130s,
   resolver: "blocklist loaded", no error

Concurrent runs are already guarded in scripts/unbound/blocklists.py (fcntl.flock(... LOCK_EX | LOCK_NB) on /tmp/unbound-download_blocklists.tmp), so detaching does not introduce overlapping rebuilds.

Side note (core, not this plugin): on this timeout configctl still exits with code 0, so callers cannot detect the failure from the return code.

Environment

OPNsense 26.7.9_1 (amd64)
os-q-feeds-connector 1.6_1 (the line is unchanged on master, PLUGIN_VERSION 1.7.d)
Intel Core Ultra 7 155H, 48 GB RAM

AI disclosure

This report and the proposed fix were prepared with the help of an AI assistant (Claude). The analysis was done on my own OPNsense system: the log excerpts are real, and both tests (configctl unbound dnsbl vs. configctl -d unbound dnsbl) were run on my firewall. I reviewed the report before submitting.

Lingua principale
PHP
Stelle
1.2k
Fork
909
Merge medio
1g 23h
PR unite (30g)
17

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opnsense/plugins

Tutte le issue di opnsense/plugins

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.