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>
next in thread | previous in thread | raw e-mail | index | archive | help
On June 26, 2019 7:54:23 AM PDT, Ian Lepore <ian@freebsd=2Eorg> wrote: >On Wed, 2019-06-26 at 05:07 +0000, Poul-Henning Kamp wrote: >> -------- >> In message < >> bf597c3830ebabbef6ac422a5d648e1eed13fac5=2Ecamel@freebsd=2Eorg>, 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=2Econf=2E T= he >> > 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=2E >>=20 >> You should consider fifolog(1) in such environments=2E >>=20 >>=20 > >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=2E > >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=2E=20 > >-- Ian > >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" I suppose another knob to control the flow of syslog is ok but filling /va= r or however a person configures /var with multiple mount points, this is u= ltimately an AO problem=2E A monitor to invoke newsyslog, among other thing= s when a threshold is exceeded, whether %, free GB, or combination or slidi= ng scale, is a better job for an event handler=2E Devd is already an event = handler=2E Teaching devd and the kernel to trigger an % or GB event to subs= equently spawn a script or process to clean up, like calling newsyslog, cle= aning out /var/tmp, spool, cache, or elsewhere, let's say, a holistic appro= ach, might have broader application than a point solution=2E Just a thought=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert <Cy=2ESchubert@cschubert=2Ecom> FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79F61714-D4EC-4A15-90AF-0E48BE684244>