Problem/Justification
Currently, if the user has third party apps/services (from the app catalogue for example) it wants to rotate logs for since they are mounted to a dataset, you can’t really do it with logrotate that is already built into TrueNAS itself.
This because the only configuration directory configured for (include /etc/logrotate.d) is not persistent across updates.
What TrueNAS can implement, and it would be quite easy, is to add to /etc/logrotate.conf an additional logrotate configuration path. Instead of just
include /etc/logrotate.d
it could be
include /etc/logrotate.d
include /etc/logrotate.user.d
with the /etc/logrotate.user.d being mounted to a persistent storage, perhaps the same one as Apps/Docker storage the user manually selects.
Impact
Advantages:
- Would allow users to have more control over log files their apps generate, potentially saving on some space occupied by old, useless logs generated by apps that themselves aren’t capable of log rotation.
- Doesn’t affect existing workflow for users or system operations whatsoever, is only complimentary functionality
- No UI work required to implement
Disadvantages: - There would need to be some documentation written for users to know about this feature (I volunteer!)
- If logrotate’s state file is not made persistent either (which would impact existing functionality), monthly logrotate rotations wouldn’t really work reliably, because the state file would be lost across updates, and logrotate only begins to rotate monthly after 2 months. This could just be documented as a caveat, most users would only need weekly or daily rotation.
User Story
I have Traefik set up on my TrueNAS setup, which generates 2 types of log files: traefik.log and access.log. While Traefik can rotate the former, it can’t do the latter, in fact docs basically tell you to user logrotate to rotate the access.log.
And rotate it you must - just after a couple of months without rotation, my access.log dataset for traefik grew to a few hundred megabytes, and that’s with LZ4 compression with ratio of almost 9.
I wrote a logrotate config for traefik, which ran weekly and did work, but it got lost when I updates to 25.04.1 
I considered using a dockerized version of logrotate, but this wouldn’t really work for Traefik, as you need to send a USR1 kill signal for it to close and reopen its log files, and I am not aware of a way for one container to send a custom kill signal to another, this needs to be done by a host logrotate.
Turning off access.log is not an option - it is required for Crowdsec to analyze Traefik’s clients.