mirror of
https://github.com/Security-Onion-Solutions/securityonion.git
synced 2026-08-16 20:52:26 +02:00
Mike Reeves
fe4f7ad2f7
so-telegraf-partition-repair cleared the backlog but left the cause in place: pg_cron's launcher is still dead, so the grid re-stalls as soon as it walks off the premade window. Operators on the preview release need something they can run once, before they soup, that leaves Telegraf collecting again. Replace it with so-telegraf-repair, which fixes both halves. The running release already creates the pg_cron extension and registers telegraf-partman-maintenance in so_telegraf; only the launcher is missing, because so_telegraf did not exist when the postmaster started. Restarting so-postgres is therefore enough to get the existing job firing, so this touches no configuration and duplicates none of the postgres state's SQL -- group_role still migrates the job to the postgres database on the next soup. It also reconciles premake to 7 and prefers so_admin.telegraf_maintenance() when that state has already landed. Exit status separates healthy (0) from needs-repair (1) from does-not-apply (2), which is what soup now gates on. postupgrade_changes runs after the highstate, so the database is already converted by then and the backlog is the only thing left to detect. Truncating is destructive and most grids were never affected -- fresh installs in particular, since they have no Telegraf history at all -- so soup asks first and skips silently rather than clearing defaults on every host.