[systemd-devel] How to quiet cron sessions logging with systemd-212?

Leonid Isaev lisaev at umail.iu.edu
Mon Jun 9 12:07:58 PDT 2014


On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote:
> Date: Mon, 09 Jun 2014 20:08:43 +0200
> From: Reindl Harald <h.reindl at thelounge.net>
> To: systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] How to quiet cron sessions logging with
>  systemd-212?
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
>  Thunderbird/24.5.0
> 
> 
> 
> Am 09.06.2014 17:28, schrieb Leonid Isaev:
> > On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote:
> >> Date: Mon, 09 Jun 2014 10:48:31 +0300
> >> From: Leho Kraav <leho at kraav.com>
> >> To: Reindl Harald <h.reindl at thelounge.net>,
> >>  systemd-devel at lists.freedesktop.org
> >> Subject: Re: [systemd-devel] How to quiet cron sessions logging with
> >>  systemd-212?
> >> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
> >>  Thunderbird/24.5.0
> >>
> >> On 09.06.2014 10:43, Reindl Harald wrote:
> >>> nobody cares because the developers point of view is that what is
> >>> interesting for them needs to be also faced by the sysadmin
> >>>
> >>> otherwise this would be only logged in debug-mode and bugreports
> >>> not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3
> >>>
> >>> frankly if that messages would at least have a prefix or a different
> >>> process than systemd one could filter them out with rsyslog.conf
> >>> without supress relevant boot messages
> >>
> >> Thanks for the info. I tried googling for this relatively hard, couldn't
> >> find that bug.
> >>
> >> Language on that bug is probably counterproductive, but other than that,
> >> some reasonably sensible way should exist to simply stop logging crap, not
> >> relying on just output filtering.
> > 
> > What you see are authpriv-level logs, so it would be a really bad idea to
> > suppress them, regardless of their source
> 
> no user needs them, there are already logs which command was
> started for which user from crond with just 3 lines

If you don't need them -- OK, but don't speak for the others. Why systemd
should be treated any differently than other programs? If it generates authpriv
messages -- they should be collected, not ignored. What about normal, i.e.
user-initiated logins -- should they be logged?

> 
> Jun  9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly)
> Jun  9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron
> Jun  9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron
> Jun  9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly)
> Jun  9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron
> Jun  9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron
> 
> they are introduced in that floody way with recent systemd
> 
> all the decades before crond did run fine, logs exactly what
> you need to know if /var/log/secure and /var/log/crond
> without writing *hundret thousands* loglines all day long
> on machines with a lot of cronjobs

But why can't you write a syslog filter which uses facility as well as program
name? So if you believe that systemd-generated messages are useless, drop them,
or store them in a volatile location like /run/log. Something like this (in
syslog-ng language):
---
destination d_systemd { file("/run/log/systemd.log"); };
filter f_daemon { facility(daemon) and not level(debug) and not \
	program(systemd); };
filter f_systemd { program(systemd); };
log { source(src); filter(f_systemd); destination(d_systemd); };
---

-- 
Leonid Isaev
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
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140609/78b9da6b/attachment.sig>


More information about the systemd-devel mailing list