IPSC3 applies bounded retention to operating-system logs, the daemon's optional application log, MySQL binary logs, and transient database telemetry. Rotation and cleanup run outside the radio daemon, not inside its live packet loop. Low-priority CPU and I/O scheduling reduce competition with voice processing; maintenance still consumes shared host resources.
| Data | Default Policy |
|---|---|
| systemd journal | 14 days, with a 512 MB persistent storage cap and compression enabled. |
| Syslog, authentication, kernel, firewall and fail2ban logs | Checked every 15 minutes; rotated daily or above 64 MB; 14 rotations retained and compressed. |
| Apache access and error logs | Checked every 15 minutes; rotated daily or above 64 MB; 14 rotations retained and compressed. Includes the master server's nested API/wiki log directory. |
| IPSC3 application log | Checked every 15 minutes; rotated daily or when it exceeds 128 MB; 14 rotations retained with archived generations compressed. |
| MySQL error log | Ubuntu's log-reopen procedure retained; checked every 15 minutes, rotated daily or above 64 MB, seven rotations retained. Empty logs are not rotated. |
| MySQL binary log | Seven-day recovery window with automatic expiry. |
| Wiki container logs | Docker-native JSON log rotation: 20 MB per file, five files per container, with rotated files compressed. |
File-size thresholds are checked periodically, not enforced byte-by-byte. A busy log can exceed its threshold between checks, and 14 rotations does not promise 14 days when size-based rotation happens more often. Syslog, Apache and fail2ban keep the newest rotated file uncompressed for one rotation so writers can finish reopening safely. Older generations use fast compression. Existing distribution log-reopen hooks are preserved. The application log uses copy/truncate because its writer does not reopen on a signal; a small copy/truncate race remains inherent to that method.
The September 2026 audit applied these policies to VK, ZL, UK, US, FreeDMR-UK and the API/master/wiki host. Existing call, SMS and GPS histories were not removed or shortened. Voice daemons do not need to restart for log rotation. Applying container log limits to existing wiki containers requires recreating those containers while preserving their data volumes.
A daily low-priority systemd service removes expired rows in batches of 2,000. Small batches and idle I/O scheduling avoid long table locks and reduce contention with live routing and dashboard updates.
| Data | Retention | Reason |
|---|---|---|
| Call events | 400 days | Preserves complete 12-month reports and the known-user API. |
| Raw APRS/DMR captures | 30 days | Protocol diagnostics only; decoded GPS history is kept separately. |
| Runtime performance samples | 7 days | High-frequency operational telemetry. |
| bMaster+ published peer telemetry | 7 days | Current transport diagnostics rather than permanent configuration. |
| Viewer heartbeats | 1 day after last activity | Transient viewer-presence state. |
| Completed or failed signal requests | 90 days | Operational prompt and signalling history. |
| Page dwell aggregates | 400 days | Long-term dashboard and CMS usage trends. |
| Expired dashboard sessions | Removed after expiry | Authentication housekeeping. |
Automatic maintenance does not delete SMS store-forward history, AI SMS requests and replies, dashboard audit records, RadioID data, hotspot token revocations, or decoded GPS position history. These records are either security-sensitive, deliberately historical, or part of the network's durable operating data.
The standard installer and upgrader apply the same bounded system-log policy.
Administrators can also run sudo bash scripts/configure-log-retention
from an IPSC3 installation, or use --system-only on the API/master
host. The helper backs up changed configuration under
/var/backups/ipsc3-log-retention-*, validates logrotate syntax,
retains distribution reopen hooks and refuses unfamiliar multi-block
policies. It enables the timers without restarting the radio services or
changing database retention. The journal service is restarted only when its
configuration changes.
Rotation does not manage source/build caches, release backups, downloads, operator files or retained research recordings. Disk alerts must remain enabled. MySQL's seven-day binary-log window is a time limit, not a byte cap; higher write volume requires more disk space even when expiry is working.
Database retention defaults can be overridden by an administrator through
/etc/default/ipsc3-database-maintenance. A dry run reports the
number of rows eligible for removal without changing the database. The
maintenance service is independent of the IPSC3 daemon and does not require
a daemon restart.