svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 11:24 -0700, Ngie Cooper (yaneurabeya) wrote:
> > 
> > On May 15, 2017, at 10:47, Ngie Cooper (yaneurabeya) <yaneurabeya at g
> > mail.com> wrote:
> > 
> > 
> > > 
> > > On May 15, 2017, at 10:43, Ian Lepore <ian at FreeBSD.org> wrote:
> > …
> > 
> > > 
> > > That's only a good argument for keeping the lines in the
> > > monolithic
> > > file if those lines will be ignored when a file in the .conf.d
> > > directory provides conflicting config.  Otherwise my embedded
> > > product
> > > that drops different rules for rotating /var/log/messages into
> > > .conf.d
> > > STILL has to programmatically edit the monolithic file to remove
> > > the
> > > standard rule(s).
> > 	Bingo. This is part of the reason why I did this, apart from
> > being selfish in not wanting to handle a handful of unnecessary
> > entries in newsyslog/syslogd on all of my systems where I set these
> > knobs to no.
> > Literally all I did was `dd+p` in vim in the new files. I didn’t
> > add or subtract any overall entries.
> And for context, we (Isilon) run newsyslog more frequently than
> upstream (sometimes every couple minutes, sometimes multiple times an
> hour/day), attributing to unnecessary creation and modification of
> log files (like this) that we (Isilon) don’t care about at all, which
> causes other potential issues with root media wear, potential for
> filesystem corruption, reduced number of available inodes/space
> because it allocates at least the frag size for a file, etc.
> 

We also run log rotation frequently (every 5 minutes) on our embedded
systems.  That was super-important back when we logged to a ram
filesystem, then newsyslog would rotate and compress from there to
sdcard.  Now we just log to sdcard because when something goes wrong
it's almost always the end of the log that has the clues (unless
something triggers runaway log spewage) and we often lost it.

A local modification we still apply to our syslogd allows you to
specify in syslog.conf that for any given file, syslogd itself should
limit the size of that file if the rotation doesn't take care of it
soon enough.  That was important to prevent filling up a ram filesystem
with runaway logging.  Now it's a feature we don't use much, but before
I throw it overboard I thought I'd mention it here in case others have
any use for it...

The way the feature worked was you could put at the end of a line in
syslog.conf "R nnnnK" -- the 'R' had a historical meaning that's now
lost, so we bacronymed it to mean "Recycle" -- when the log grows to
nnnnK in size, the last 32K of the file becomes a circular buffer that
continually gets rewritten until a normal file rotation happens.  If
something triggers runaway logging, the hope is that that event got
captured somewhere before the final 32k of the file, so you still have
some clues for postmortem analysis.

-- Ian