On Fri, Mar 13, 2015 at 06:35:38PM -0400, Chris Morgan wrote: > Hello. > > I posted this, > http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html, > 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. You should be able to do something like this right now with journal-remote: journalctl --directory /run/log/<bootid> -o export | \ systemd-journal-remote -o /var/log/<bootid>/ -
This is a bit too hacky to put into production, and it would be better to have a single binary which does this. But all the parts are there: - following the journal and filtering, - opening of specific directory as input, - saving of state (i.e. the last cursor written), - writing to a directory and rotating files the same as journald does. So adding a new binary (or extending one of the existing ones) supporting your use case would be a matter of hooking stuff together. > 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. Adding filtering and splitting functionality to journald is another story of course. It probably would work better: more efficent, and journal entries would not be duplicated at all. > 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. I think that supporting a set of similar filters to journalctl would be a good start. Options which limit the number of messages or filter based on time would not make sense for journald, but most other probably would. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
