Problem/Justification
If I understand correctly, by default the docker daemon doesn’t have a log size limit. Users can specify logging options in compose files but I suspect most people won’t bother.
Impact
Container logs will eventually fill up drives if left unattended.
User Story
Since we are using the json-file driver, we should set a sane (and maybe user configurable) max-size limit in daemon.json.
I could be wrong since I don’t really use them, but I think currently there is no way to change this for built-in apps either, unless they all come with a limit set in compose in the apps catalogue, though that’s still not user configurable.
I know very little about this, but I did notice alot of apps let you specify local datasets for config and data. I would imagine the data directory would be storing logs, so you could set quotas on the dataset to keep the logs from overrunning your storage right?
But I agree with the concept, I mean most loggers are designed to rotate logs at a specific fill point; it would be nice to set that fill point size.
You could, but its really not the same.
First, you have to have a seperate dataset for just the logs subpath that you bind mount independently, or else the quota would needlessly impeed the rest of the app storate.
Second, all this would acheive is preventing overrun, which while good, still requires you to manually clean them out now and then or else you lose all logging.
Third, due to the nature of quotas, as they start to get close to full the peformance of them will degrade which may cause additional overhead on the system, though it may be marginal.
Dockers log system inherently has an option to limit log sizes in a way where they are automatically rotated out, as well as limit how many old files are stored, meaning the logs could be written to indefinitely without issue. Log rotation, as you mentioned.
For users making custom compose files, you can add the rotation settings yourself, but its nice to have a system wide default so you dont need to do it for every container (bloating the yml). Then, as I mentioned, built-in apps have no way to do this currently.
So my method would be a band-aid but we need another way to inject that option into the yaml files for each app. @Helium, you got my vote, I see the utility here.
Yes, but it doesnt even require anything special. The value in the docker daemon config mentioned in the OP sets the property system wide, one needs simpy change it and restart the dameon to see the effect.
The issue is that since TrueNAS is an appliance, that change is generally lost on reboot and/or upgrade, unless you use something like a startup script to update it everytime. In this case you would need to read in the existing file parse the JSON to add the value in question as it isn’t there by default and you must not disturb the existing options, so it would be a bit complicated. Additionally, its not clear if the pre-init would run before the docker daemon actually starts (my guess is yes though).
But instead of dealing with all of that, iX could add a UI entry somewhere where you could just put in your own values for the properties related to docker logging and the middleware would take care of transferring that to the actual config file. Then its supported and will persist over time.
Essentially, docker has a builtin way to apply this globally already thats easy to change on a normal Linux system, but that isn’t the case on an appliance like TN until they add official support for it through the UI.
Thank you for submitting this feature request. After keeping it open to gauge community interest, we’re closing it as it hasn’t received enough votes to prioritize for development.
