logs: block controls how snapr writes log files to disk.
snapr always emits two streams in parallel:
- stdout — human-readable lines with ANSI color. Never disabled, never written to disk by snapr itself.
- files — JSON-line events on disk, rotated by snapr. This is what the API and UI read from.
Layout on disk
When both flags are on (the default), the layout is:[A-Za-z0-9._-] collapse to _ to keep filenames safe.
Fields
path is resolved relative to the process working directory. Use an absolute path in production (for example,
/var/log/snapr).Example
snapr.yaml
Disabling files
Setsystem: false and/or perJob: false. With both off, snapr creates no file sink and the API endpoints return:
journalctl, docker logs, or your container runtime still see everything.
Edge cases
- Lumberjack rotation is in-process. A second snapr process pointed at the same
pathwill fight for rotation. Don’t run two instances against one log directory. - No external rotation needed. Don’t combine snapr’s rotation with
logrotate(8)/copytruncate. Set snapr’smaxSizeMB: 0if you’d rather an external tool own rotation. - Disk full. Lumberjack swallows write errors silently to keep the process alive. The same event still hits stdout, so external collectors keep working.
- Removed jobs. When you delete a job from the config, its
jobs/<name>.logis left in place. Clean up manually if needed. - Renamed jobs. A rename starts a new file under the new name; the old file is not migrated.
server.enabled: false(scheduler-only mode). File logs still work the same way; only the API endpoints that read them are gone.- Permissions. snapr creates
pathwith0755and files with lumberjack’s default (0600). Make sure the process user can write there — failure to create the directory aborts startup.