Date: Wed, 26 Jun 2019 08:15:05 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: freebsd-hackers@freebsd.org, Ian Lepore <ian@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-embedded@freebsd.org Subject: Re: Limiting the size of syslogd output files using options in syslog.conf Message-ID: <79F61714-D4EC-4A15-90AF-0E48BE684244@cschubert.com> In-Reply-To: <fd26f9c77fc16fb7aa416bcd7b5eb8f91591f15c.camel@freebsd.org> References: <bf597c3830ebabbef6ac422a5d648e1eed13fac5.camel@freebsd.org> <30082.1561525622@critter.freebsd.dk> <fd26f9c77fc16fb7aa416bcd7b5eb8f91591f15c.camel@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On June 26, 2019 7:54:23 AM PDT, Ian Lepore <ian@freebsd.org> wrote: >On Wed, 2019-06-26 at 05:07 +0000, Poul-Henning Kamp wrote: >> -------- >> In message < >> bf597c3830ebabbef6ac422a5d648e1eed13fac5.camel@freebsd.org>, Ian Le >> pore writes: >> > I've posted a review of a small syslogd change which lets you set a >> > limit on the size of syslogd output files in /etc/syslog.conf. The >> > idea is to prevent filling up a filesystem on emmc or sdcard or >> > other >> > small storage device on an embedded system with unexpected logging >> > triggered by some error or failing hardware. >> >> You should consider fifolog(1) in such environments. >> >> > >fifolog looks pretty cool and I had no idea it existed, so thanks for >the pointer; I may find useful things to do with it. > >But for the problem of unexpected syslog spewage it has exactly the >same problem as running newsyslog very frequently: by design it >discards the information you most want preserved (the triggering event >that led to unexpected log spewage) while carefully preserving all the >following noise which is typically more about symptoms rather than >causes of the problem. > >-- Ian > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd.org" I suppose another knob to control the flow of syslog is ok but filling /var or however a person configures /var with multiple mount points, this is ultimately an AO problem. A monitor to invoke newsyslog, among other things when a threshold is exceeded, whether %, free GB, or combination or sliding scale, is a better job for an event handler. Devd is already an event handler. Teaching devd and the kernel to trigger an % or GB event to subsequently spawn a script or process to clean up, like calling newsyslog, cleaning out /var/tmp, spool, cache, or elsewhere, let's say, a holistic approach, might have broader application than a point solution. Just a thought. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79F61714-D4EC-4A15-90AF-0E48BE684244>