Mysql error log never purged

[jdougan]

So, I'm trying to determine why the compressed grain backup size of my tt-rss installation has ballooned in the last month from 350M to around 850M. The most significant change has been upgrading the OS to Ubuntu 18, which let me upgrand/install sandstorm, which apparently update to a newer version of tt-rss sandstorm.

In the process of looking for this, I noticed that the mysql error.log is currently at 1GB in size, with entries going back to 2016 (and at least one log format change). Is there any mechanism to purge/rotate or otherwise manage the mysql error.log.? How does the non-sandstorm version of ttrss handle this?

Edit: rewrote for clarity

[ocdtrekkie]

This is definitely something we should address, I'll do a little exploring, my own grain is quite old (and quite large).

We probably shouldn't retain much longer log files than the grain log itself.

[zenhack]

The non-sandstorm version probably relies on system-wide log rotation policies.

Once we figure out a solution here we should probably incorporate it into vagrant-spk's lemp stack; this probably affects other apps as well.

Maybe we just add something like this to launcher.sh:

if [ $(du -b /path/to/log) -ge $some_limit ]; then
   mv /path/to/log /path/to/log.1
fi

this would only rotate the logs on start, but that's probably fine for most apps.

[zenhack]

And yeah, my own error.log is 480MB, while the grain as a whole is 582MB

[zenhack]

I opened #45, which should fix this.