From nobody Tue Nov 22 15:47:10 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGpYL57Zjz4hwPL for ; Tue, 22 Nov 2022 15:47:34 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGpYL4kH7z4Ql2 for ; Tue, 22 Nov 2022 15:47:34 +0000 (UTC) (envelope-from mack@macktronics.com) Authentication-Results: mx1.freebsd.org; none Received: from olive.macktronics.com (unknown [209.181.253.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.macktronics.com (Postfix) with ESMTPS id E47021D0; Tue, 22 Nov 2022 09:47:10 -0600 (CST) Date: Tue, 22 Nov 2022 09:47:10 -0600 (CST) From: Dan Mack To: Alexander Kabaev cc: freebsd-current@freebsd.org Subject: Re: dmesg content lifetime In-Reply-To: <20221122104445.4ed88f6f@kan> Message-ID: References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com> <20221122104445.4ed88f6f@kan> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4NGpYL4kH7z4Ql2 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, 22 Nov 2022, Alexander Kabaev wrote: > On Tue, 22 Nov 2022 09:12:28 -0600 (CST) > Dan Mack wrote: > >> It seems like dmesg content ages out over time. Is there a way to >> leave the contents based on a fixed memory size instead? >> >> Dan >> > I think this is how it works: the kernel message bugger is of fixed > size and kernel and syslog sequences (dmesg -a) share it. The other > syslog users eventually puts enough content in there to displace all of > kernel messages. If the kernel stays quiet, 'dmesg' then returns > nothing, as by default it filters syslog entries that do not KERN > facility out, see sbin/dmesg/dmesg.c. > > -- > Alexander Kabaev > Thank you Alexander, I did not know this. I'll USL (use-the-source-luke) :-) Dan