Re: [systemd-devel] Both volatile and persistent journald logs
Lennart Poettering lenn...@poettering.net writes: On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote: The specifics of my logging that is temporarily volatile is captured in these rsyslog configs: local1.*/tmp/log/dnsmasq.log local4.*/tmp/log/ldap.log if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then /tmp/log/firewall.log journald does not allow seperate log files or filter expressions, please use rsyslog or another syslog daemon for things like this. I've got no real use for directing logs to files via these filter expressions in a journald world. I'm happy with the filtering being done on read-out instead of ingestion. These only go to separate files because that's how syslog works. But if I want to discriminate in order to direct logs to a volatile vs persistent store then I would need some sort of pre-filtering and I can see how that does not fit with journald's design. However, even if I continue to use rsyslog with these filters, I don't believe I will achieve what I want because the logs will first pass through journald which will happily write them to its journal on /var/log, creating the SSD write activity I'm trying to avoid. For now I guess I'll just reduce the amount of logging. I should be able to use NFLOG and ulogd2 to capture the firewall logs outside of syslog/journald. Thanks for your quick response. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Both volatile and persistent journald logs
On Thu, 23.04.15 12:08, Cam Hutchison (c...@xdna.net) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote: The specifics of my logging that is temporarily volatile is captured in these rsyslog configs: local1.*/tmp/log/dnsmasq.log local4.*/tmp/log/ldap.log if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then /tmp/log/firewall.log journald does not allow seperate log files or filter expressions, please use rsyslog or another syslog daemon for things like this. I've got no real use for directing logs to files via these filter expressions in a journald world. I'm happy with the filtering being done on read-out instead of ingestion. These only go to separate files because that's how syslog works. But if I want to discriminate in order to direct logs to a volatile vs persistent store then I would need some sort of pre-filtering and I can see how that does not fit with journald's design. However, even if I continue to use rsyslog with these filters, I don't believe I will achieve what I want because the logs will first pass through journald which will happily write them to its journal on /var/log, creating the SSD write activity I'm trying to avoid. Use Storage=volatile in journald.conf to turn off storage in /var. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Both volatile and persistent journald logs
I am migrating to systemd/journald (via an upgrade from Debian wheezy to jessie) and I've come across a problem migrating that is peculiar to my setup. I currently have /var/log on an SSD. I also have some noisy logs. In attempt to not have rsyslog write continuously to the SSD, I have set up some syslog facilities and special filters to log to /run/log files instead of /var/log for those noise logs. I have an hourly cron job that runs logrotate on the /run/log files and appends the rotated log (the .1 file) to the persistent logs in /var/log. I would like to be able to do something similar with journald. The specifics of my logging that is temporarily volatile is captured in these rsyslog configs: local1.*/tmp/log/dnsmasq.log local4.*/tmp/log/ldap.log if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then /tmp/log/firewall.log I am aware that on an unclean shutdown these logs get lost. I am ok with that. They are mostly useful for realtime debugging and not historical analysis. In the rare event of an unclean shutdown, I accept this loss (I've not yet had such a shutdown). Is there a way to configure journald to do something similar? Is there some other mechanism that can address excessive log writing to an SSD? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Both volatile and persistent journald logs
On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote: I am migrating to systemd/journald (via an upgrade from Debian wheezy to jessie) and I've come across a problem migrating that is peculiar to my setup. I currently have /var/log on an SSD. I also have some noisy logs. In attempt to not have rsyslog write continuously to the SSD, I have set up some syslog facilities and special filters to log to /run/log files instead of /var/log for those noise logs. I have an hourly cron job that runs logrotate on the /run/log files and appends the rotated log (the .1 file) to the persistent logs in /var/log. I would like to be able to do something similar with journald. The specifics of my logging that is temporarily volatile is captured in these rsyslog configs: local1.*/tmp/log/dnsmasq.log local4.*/tmp/log/ldap.log if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then /tmp/log/firewall.log journald does not allow seperate log files or filter expressions, please use rsyslog or another syslog daemon for things like this. The idea behind the journal is to place everything in a big pool and filter on read access only, only splitting things into multiple files where rotation or access control demand it. I am aware that on an unclean shutdown these logs get lost. I am ok with that. They are mostly useful for realtime debugging and not historical analysis. In the rare event of an unclean shutdown, I accept this loss (I've not yet had such a shutdown). Is there a way to configure journald to do something similar? Noep, sorry. Is there some other mechanism that can address excessive log writing to an SSD? There has been a feature request to allow writing to journal files in /run and /var in parallel, arbitrating by the log level. I'd be happy to support something like that, which would allow storing debug messages only in /run, but the more important one in /var. However, that's not going to deliver what you are asking for. Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
