Skip to content

Error on SQL save due tu column 'seq' dosen't exist, but it does #331

Description

@arno-st

on Cacti 1.2.31, and syslog 4.2

I'm getting some error of this kind:
27/08/2026 15:44:25 - CMDPHP SQL Backtrace: (/plugins/syslog/syslog_process.php[213]:syslog_process_alerts(), /plugins/syslog/functions.php[1333]:syslog_process_alert(), /plugins/syslog/functions.php[1642]:syslog_log_alert(), /plugins/syslog/functions.php[945]:syslog_sql_save(), /plugins/syslog/database.php[222]:sql_save())

27/08/2026 15:44:25 - DBCALL ERROR: SQL Save on table 'syslog_prod.syslog_logs': Column 'seq' does not exist, unable to save!

I have a separate Database for syslog, it's look like the alert log is empty.

I manually made a query to check that the column exist, (like done in /lib/database.php) and it does.
I can't find why this error show up.
I thinks it's happen after the upgrade to 1.2.31, but even that I can't find in the code what is wrong

Activity

  1. arno-st commented on Aug 27, 2026

    @arno-st
    ContributorAuthor

    Ho and if I edit an alert filter, then save it, I have this error:
    SQL Save on table 'syslog_prod.syslog_alert': Column 'id' does not exist, unable to save!
    Save Failed.

  2. arno-st commented on Aug 27, 2026

    @arno-st
    ContributorAuthor

    Well even worse: Removal rules react the same.

  3. TheWitness commented on Aug 27, 2026

    @TheWitness
    Member

    Can you trace it to Cacti or Syslog? Did you update one or both?
    @somethingwithproof FYI.

  4. TheWitness commented on Aug 27, 2026

    @TheWitness
    Member

    @somethingwithproof , it looks like a breaking fix from upstream. Can you address it? If it's fixed here, we need to ensure that it's portable to earlier Cacti releases, or update the INFO file for 1.2.31++.

  5. somethingwithproof commented on Aug 27, 2026

    @somethingwithproof
    Member

    Confirmed: this is a Cacti core regression, not a missing Syslog column.

    The regression is in Cacti commit aa1faf3e0 / Cacti #7235. sql_save() asks db_get_table_column_types() for metadata using the qualified table name and the Syslog PDO connection. The hardening change made that helper accept only a single unqualified identifier and then wrap the full value in one pair of backticks. Syslog's valid database.table form is therefore rejected, the metadata array is empty, and sql_save() reports every submitted key (seq, id, etc.) as missing.

    db_table_exists() already supports qualified table names, and the Syslog wrapper is correctly passing the separate connection. The correction belongs in Cacti core: parse an optional database qualifier, validate both identifier components independently, and quote them as separate identifiers. It should be applied to both 1.2.x and develop so Syslog remains portable; changing the plugin INFO minimum would only mask the core compatibility break.

    This also explains why alerts, alert logs, and removal rules all fail together. I'm treating this as a core regression rather than a plugin schema issue.

  6. somethingwithproof commented on Aug 27, 2026

    @somethingwithproof
    Member

    The core fix is now open as Cacti/cacti#7826.

    It restores Syslog's quoted database.table metadata lookup while preserving the identifier hardening by validating and quoting the database and table components independently. The PR includes regression coverage for the exact Syslog form and unsafe/malformed identifiers.

    This regression is specific to 1.2.x; current Cacti develop still accepts the qualified form, so no plugin compatibility workaround or INFO version bump is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions