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

Abierto Apto para principiantes
#5,923 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cli, linux, python

Línea de trabajo

La llamada que falla es subprocess.run de configctl en security/q-feeds-connector/src/opnsense/scripts/qfeeds/lib/init.py, dentro de QFeedsActions.unbound_load. Léelo junto con la guarda flock en scripts/unbound/blocklists.py para confirmar que las ejecuciones concurrentes siguen bloqueadas. La solución es añadir el flag -d a esa llamada a configctl. Se considera terminado cuando no se registra ningún error de configd tras una reconstrucción exitosa de DNSBL que tarda más de 120 segundos; el reportante lo probó manualmente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
PHP
Estrellas
1.2k
Forks
909
Merge medio
1 d 23 h
PR fusionados (30 d)
17

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de opnsense/plugins

Todos los issues de opnsense/plugins

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.