Limiting the size of syslogd output files using options in syslog.conf

Cy Schubert Cy.Schubert at cschubert.com
Wed Jun 26 15:15:38 UTC 2019


On June 26, 2019 7:54:23 AM PDT, Ian Lepore <ian at freebsd.org> wrote:
>On Wed, 2019-06-26 at 05:07 +0000, Poul-Henning Kamp wrote:
>> --------
>> In message <
>> bf597c3830ebabbef6ac422a5d648e1eed13fac5.camel at 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 at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to
>"freebsd-hackers-unsubscribe at 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 at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.


More information about the freebsd-hackers mailing list