Are you sure all your pollers are up to date because that error with the line number means you’'re hitting a blank line of the code so it doesn’t look possible to error:
Thank you for the suggestion @laf!
We’ve only 1 additional poller running as a Podman container on the same machine with the following config:
services:
dispatcher:
image: librenms/librenms:latest
container_name: librenms_poller1
hostname: librenms-poller1
volumes:
- "/opt/librenms:/data"
environment:
- "APP_KEY=${APP_KEY}"
- "TZ=${TZ}"
- "PUID=${PUID}"
- "PGID=${PGID}"
- "DB_HOST=${DB_HOST}"
- "DB_NAME=${DB_NAME}"
- "DB_USER=librenms"
- "DB_PASSWORD=${DB_PASSWORD}"
- "DB_TIMEOUT=${DB_TIMEOUT}"
- "REDIS_HOST=${REDIS_HOST}"
- "REDIS_USERNAME=${REDIS_USERNAME}"
- "REDIS_PASSWORD=${REDIS_PASSWORD}"
- "REDIS_TIMEOUT=${REDIS_TIMEOUT}"
- "RRDCACHED_SERVER=${RRDCACHED_SERVER}"
- "DISPATCHER_NODE_ID=poller1"
- "SIDECAR_DISPATCHER=1"
logging:
options:
max-size: 10m
max-file: 3
restart: always
I did forget to pull a fresh container, but after I did that the error, albeit changing, did not disappear:
[2025-06-24T11:39:01][ERROR] SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘alert_rules.rule’ in ‘field list’ (Connection: dbFacile, SQL: SELECT alert_log.id,alert_log.rule_id,alert_log.device_id,alert_log.state,alert_log.details,alert_log.time_logged,alert_rules.rule,alert_rules.severity,alert_rules.extra,alert_rules.name,alert_rules.query,alert_rules.builder,alert_rules.proc FROM alert_log,alert_rules WHERE alert_log.rule_id = alert_rules.id && alert_log.device_id = 66 && alert_log.rule_id = 13 && alert_rules.disabled = 0 ORDER BY alert_log.id DESC LIMIT 1)#0 /opt/librenms/LibreNMS/Alert/RunAlerts.php(444): dbFetchRow()
#1 /opt/librenms/LibreNMS/Alert/RunAlerts.php(477): LibreNMS\Alert\RunAlerts->loadAlerts()
#2 /opt/librenms/alerts.php(61): LibreNMS\Alert\RunAlerts->runAlerts()
#3 {main}
Validation is still good (we had that error since the very beginning):
===========================================
Component | Version
--------- | -------
LibreNMS | 25.6.0-48-gc72056e48 (2025-06-24T01:18:10+03:00)
DB Schema | 2025_06_11_173916_drop_alert_rule (344)
PHP | 8.3.14
Python | 3.6.8
Database | MariaDB 10.3.39-MariaDB
RRDTool | 1.7.0
SNMP | 5.8
===========================================
[OK] Composer Version: 2.8.9
[OK] Dependencies up-to-date.
[OK] Database Connected
[OK] Database Schema is current
[OK] SQL Server meets minimum requirements
[OK] lower_case_table_names is enabled
[OK] MySQL engine is optimal
[OK] Database and column collations are correct
[OK] Database schema correct
[OK] MySQL and PHP time match
[OK] Distributed Polling setting is enabled globally
[OK] Connected to rrdcached
[FAIL] Both Dispatcher Service and Python Wrapper were active recently, this could cause double polling
[OK] Dispatcher Service is enabled
[OK] Locks are functional
[OK] Python poller wrapper is polling
[OK] Redis is functional
[OK] rrdtool version ok
[OK] Connected to rrdcached
I’m not sure what you’ve done here exactly but using the docker image which tracks the stable monthly release we do, does not contain the bug in the first place as it’s not had the code merged in that drops the rule table. Somehow you have managed to run the database migrations from a newer version.
Get your versions synced, if that’s back to 25.6.0 then validate will probably complain about the schema, if it suggestions to re-add the rule column, do that and you should be ok.
Looks like maybe there’s another spot that needs fixing?
[2025-06-24T12:08:29][ERROR] SQLSTATE[42S22]: Column not found: 1054 Unknown column 'alert_rules.rule' in 'SELECT' (Connection: dbFacile, SQL: SELECT `alerts`.*, IFNULL(CONVERT_TZ(`alerts`.`timestamp`, @@global.time_zone, America/Chicago),`alerts`.`timestamp`) AS timestamp_display, `devices`.`hostname`, `devices`.`sysName`, `devices`.`display`, `devices`.`os`, `devices`.`hardware`, `locations`.`location`, `alert_rules`.`rule`, `alert_rules`.`name`, `alert_rules`.`severity` FROM `alerts` LEFT JOIN `devices` ON `alerts`.`device_id`=`devices`.`device_id` LEFT JOIN `locations` ON `devices`.`location_id` = `locations`.`id` RIGHT JOIN `alert_rules` ON `alerts`.`rule_id`=`alert_rules`.`id` WHERE `devices`.`disabled` = 0 AND `alerts`.`state`!=0 ORDER BY timestamp DESC LIMIT 0,50)#0 /opt/librenms/includes/html/table/alerts.inc.php(131): dbFetchRows()
#1 /opt/librenms/html/ajax_table.php(45): include_once('...')
#2 {main}
No, that was fixed last week: More alert fixes (#17882) · librenms/librenms@bcd736f · GitHub
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.