With logbookd, a user can (I did this!) spam writes to syslog until the system memory is full. The OOM killer might end up killing logbookd to free memory.
For a good init system, this isn't too bad since logbookd will probably be restarted. You may lose log data though (e.g. if run with -r).
On systems with limited init systems, logbookd may not be restarted. In that case, a normal user was effectively allowed to disable all system logging for the current boot by causing logbookd to get OOM killed, and I don't think that's good...
Is there some way to limit the amount of data in memory?
When rotating entries in memory, it could dump old ones to disk (e.g. -r?
I think a hard limit of 10% of system RAM, where entries in memory would be rotated so it doesn't continue to grow unbounded, would be sufficient even for devices (N900) with <1GB memory... it seems unlikely the in-memory log data would approach hundreds of MB?
Ugh, I just discovered
logbookd -g, sorry for the noise. I can't edit this todo(??!) but I think it would still be nice to have a way for entries in memory (when using-r) to be rotated to disk instead of being dropped entirely. Is this possible?
The issue with -r mode is that the on disk database is the exact same one as the one loaded in memory. So writing it out doesn't actually save memory.
That's the major tradeoff with -r mode. if it's using disk-backed logs without reduced write mode it's using the sqlite memory management and you'll avoid this issue. With pure in-memory mode logs are already dropped when memory limits are hit.