mirror of
https://github.com/Security-Onion-Solutions/securityonion.git
synced 2026-08-06 07:55:59 +02:00
Mike Reeves
5d36d00dec
pg_cron's launcher connects to cron.database_name at postmaster start and is registered BGW_NEVER_RESTART. On a host upgraded onto an existing /nsm/postgres volume, init-db.sh never runs, so so_telegraf does not exist when PostgreSQL starts -- the launcher dies and never retries. Salt then creates the database, the extension, and the schedule, all of which succeed, but no worker is left to fire the job. partman.run_maintenance_proc() therefore never runs: partitions stop being premade after create_parent's initial window and every metric lands in <parent>_default. Retention never fires either. That state is self-perpetuating. Once the default partition holds rows for a day with no child, PostgreSQL cannot create that child at all -- attaching it would violate the default partition's constraint -- so maintenance aborts on the first parent it reaches. Fixing the scheduler alone does not recover a stalled grid. Point cron.database_name at the always-present postgres database and register the job with cron.schedule_in_database targeting so_telegraf, so the launcher no longer depends on database creation order. group_role drops any registration left behind in so_telegraf, and both halves are guarded on the live GUC so applying postgres.telegraf_users before the postgresql.conf change has restarted the container skips instead of failing. Maintenance now runs so_admin.telegraf_maintenance(), which drains stranded rows out of any default partition before calling partman: expired rows are deleted, the rest are repartitioned. It runs from the state on every highstate as well as hourly from pg_cron, so a grid whose worker is dead still recovers on its own. The routines live in a postgres-owned schema so_telegraf has no rights on, since pg_cron executes them as postgres. Existing grids are recovered by a marker-guarded repair state that truncates the non-empty defaults once per host. The backlog is mostly past retention already and moving tens of GB just to delete most of it is not worth the WAL. Also raise premake from 3 to 7, reconciled onto existing parents in the retention subcommand, so an outage has a week of headroom before anything reaches a default partition, and add a check subcommand reporting partition age, default occupancy and last job status.