On Wed, 17.07.13 16:37, M A Young (m.a.young@durham.ac.uk) wrote:
I used to do something like this with vim ":g/NOISE/d" until I could see the detail I wanted when the alternations for grep would have been tremendously long. With journalctl's built-in filtering capabilities I'm glad I don't have to do that anymore; it's way more concise. However, all use cases differ, so if you must, you can: "journalctl | vim -". YMMV with other editors though.
That isn't a complete solution though because you may want to remove the bad logs completely to free up the space they are taking up. Of course you may have already lost all the interesting logs by this point with journald anyway because they have been overwritten.
That leads me to ask another question, how well does journald cope with keeping certain logs long term? The classic syslog way of doing this is to send them to a separate file, then use logrotate to compress them once they have been rotated. Is there any equivalent with journald? Compressing may be necessary due to the quantity of logs required.
Regarding retention policies we currently only have a max retention time limit which you can configure globally.
There are plans to add a bit of code to allow rotation that throws away lower priority messages earlier than high priority messages during rotation and then add individual retention time limits for that too.
However, I am not keen on adding a complex language that allows matching of specific clients or messages and then apply specific retention times to that. For that please use rsyslog which supports such a language.
Lennart