Getting inspiration from what you are proposing, you can already forward messages to a datagram socket (syslog). You could implement a program to empty out the datagram socket and only write the messages you want. Syslog format doesnt know anything about FIELD though. One down side of this implementation is that your program will be woken up for every message causing extra context switch.<div> </div><div>Regardless off this, it is interesting to hear out the thoughts about filtering. There have been discussions about per service filtering too.</div><div> </div><div>Umut On Friday, March 13, 2015, Chris Morgan <<a href="mailto:chmorgan@gmail.com">chmorgan@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello. I posted this, <a href="http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html" target="_blank">http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html</a>, some time ago about tiered logging for embedded systems. The goal is to guarantee that the flash memory will last the duration of the product by carefully controlling who writes to it. I'm back looking at the issue and wanted to re-open the discussion. One approach that came up would be to set "Storage=volatile", a limit of say "10MB" for the journal size, and then write a separate program that would filter out the journal entries and write them to a file on a physical disk. The filtering portion is required as we are using the journal to persist some important information that we'd like to log. We'd also like to preserve high priority messages but don't mind if we lose low priority ones across reboots. An upside of the external program is that we can filter on both high priority messages as well as those with specific "FIELD=value" entries. Downside is a custom format file and can't use journalctl to search through it, no log rotation, no size limits etc. At the time there was some thought of putting this into journald itself. I'm wondering how that would fit given the desire to use more complicated matching to decide which entries were put into the persisted journal. If it would fit inside of journald I'd be willing to implement it but we would need to come up with a way to configure the filtering, where the files are persisted etc. The filtering is a new requirement since the last time this was discussed. Chris _______________________________________________ systemd-devel mailing list <a href="javascript:;" onclick="_e(event, 'cvml', 'systemd-devel@lists.freedesktop.org')">systemd-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div>