docs: describe log rotation for cron output

This commit is contained in:
Release Monitor
2026-10-11 21:54:41 +07:00
committed by latypov
parent f74df22162
commit c541c6b1bf
+25 -2
View File
@@ -103,10 +103,33 @@ To track prereleases every day, set `INCLUDE_PRERELEASES=true` in `.env` instead
Run once daily at 09:00 in the server's local timezone:
```cron
0 9 * * * cd /opt/github-release-monitor && ./monitor.sh >> monitor.log 2>&1
0 9 * * * cd /srv/share/github-release-monitor && ./monitor.sh >> monitor.log 2>&1
```
Use `crontab -e` for the account running the monitor. Change `/opt/github-release-monitor` to your actual installation directory. Keep `monitor.log` under log rotation if it grows; cron output redirection does not rotate logs.
Use `crontab -e` for the account running the monitor. Change `/srv/share/github-release-monitor` to your actual installation directory. Cron output redirection does not rotate logs.
### Log rotation
To rotate `monitor.log` once it exceeds **1 MiB**, create `/etc/logrotate.d/github-release-monitor`:
```conf
/srv/share/github-release-monitor/monitor.log {
size 1M
rotate 3
missingok
notifempty
compress
copytruncate
}
```
`rotate 3` retains up to three compressed older logs. `copytruncate` works with the existing `>> monitor.log` redirection without changing the cron entry. Install/configure `logrotate` on the host and verify the rule:
```bash
sudo logrotate -d /etc/logrotate.d/github-release-monitor
```
**Note:** `logrotate` checks the size only when its scheduled job runs (typically daily). The active log can temporarily exceed 1 MiB, and rotated archives consume additional disk space. This is not a strict total-storage cap.
For troubleshooting: