[systemd-devel] right way to log to rsyslog/syslog only?
lisaev at umail.iu.edu
Thu Aug 7 15:42:17 PDT 2014
On Thu, Aug 07, 2014 at 09:44:47PM +0000, "Jóhann B. Guðmundsson" wrote:
> So basically you want to log everything to /run ( volatile ) and filter out
> everything above a certain log-level and store that persistent in it's own
> ( basically store the output from this "journalctl -p err" persistently )
> Or you want to log everything to /run ( volatile ) and filter out everything
> above a certain log-level for a specific user,unit,command whatever and
> store that persistent in it's own journal.
> ( using your example store the output from this "journalctl -p err
> _SYSTEMD_UNIT=dnsmasq.service" persistently )
My original motivation was to reduce HDD spin-ups (academic, I know). So I had
to identify sources of frequent logging activity and figure out which log
messages are actually valuable and which can be discarded on reboot. The same
rationality applies to remote logging, e.g. only auth-level events and critical
hardware telemetry should be sent to a log-server.
> One of the Samsung guys proposed something similar to the former a while
> back ( and I think he signed himself up to it ) but as far as I can tell his
> work has not landed yet.
> ( afaikt requires changes to journald-server.c|||introduce something like
> SplitMode=priority-err |etc ).
Thanks for letting me know aboout this work, but from the above description it
seems rather limited. I brought up the log-levels only as an example. In
practice one needs to be able to filter using _any_ message attribute.
For instance, message body (iptables traffic, output of frequently-run systemd
timers -- drop the useless Start/Stop-type messages, HostAp logs) and facility
> I would not expect anything like this soon since Andy NAK their SCM_PROCINFO
> stuff and they are probably to busy re-writing/re-implementing it as
> SCM_IDENTY together with him but one of the Samsung guys can comment if they
> had started working on or had otherwise looked into this but as things stand
> now this cannot be done afaikt.
IMHO, the central technical problem (I am not going to argue about design
principles) of journald is that it is an "all or nothing" solution.
Unfortunately, this inflexibility makes it only useful as a supplimentary
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the systemd-devel