Re: Certbot excessive logging
On Sun, 12 Feb 2017 18:56:39 +0100, Christian Seiler
<email@example.com> wrote :
> On 02/11/2017 09:36 PM, SaintGermain wrote:
> > Excessive was not the correct word, sorry.
> > I didn't understand that systemd was involved.
> > I will change the Loglevel, thanks for the explanation.
> I would recommend against that: if something goes wrong, then
> systemd not logging what it's doing is going to make it very
> difficult to figure the problem out if the log messages are
> not actually generated.
> You are annoyed by your automated log analysis tool (be it
> logcheck or something else) sending you these messages every
> 12 hours, not by the messages being present in the log
> themselves. I would really recommend you alter your filtering
> solution and not the log level of systemd, because the latter
> will come to bite you one day. (There's a reason why cron
> syslog messages are typically filtered in automated checking
> solutions and not completely suppressed.)
I was only logging errors (not info/debug level messages) as I was
managing my system as a normal program (i.e. only activate the debug
logs on some parts of the program, when we try to isolate a
But perhaps indeed I should log everything and filter it only for
In my limited experience however, when there was a problem, I often
managed to quickly isolate it and to activate the relevant debug
logging and reproduce the bug/problem.
With your example for instance (cron syslog message), could you provide
some rational to let it log such messages for years after being set up ?
Another reason was that I used to manage a system with the OS on a
standard hard drive. Most of the type the system was idle and not doing
anything. However info-level logging (like cron) kept the hard drive to
go on standby. So I deactivated such logs (I didn't want to create a
tmpfs drive for /var/log, this is a hot topic which has been previously
debated to no end).
Thanks for the advice though, I'll take that into consideration.