On Wed, 17.07.13 16:37, M A Young (m.a.young@xxxxxxxxxxxx) 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 -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel