From nobody Tue Nov 22 17:37:14 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 4NGs072hHdz4j8bN for ; Tue, 22 Nov 2022 17:37:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGs070jTDz3hHR for ; Tue, 22 Nov 2022 17:37:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x633.google.com with SMTP id ft34so37358909ejc.12 for ; Tue, 22 Nov 2022 09:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C9dE7tHKwWd+Q325ea3gyYmgSt9bZxfTUEi3V3Opfe0=; b=WLsR1jntFzxdaKXGHuCx1E/VBfqX43NUPKxehdfkFeo2kA2hlfB4n8KDKr3FltzFFJ Uq3aAgZczpDB7mIerLjBUPMr93dWPccWf6GBh8aA+vOHAwZ+f+IZy5cuZB6RwV3lxYcP KOxXaTGLx3iKZWXVvHspPzmttTtiqvSM2GNFebAv/eszFyP3ViORDSLlkJhmzN8veK3G iktdKlREPpGZ78XKxXS7LZerXZkkNuUISou/WjAz5WWecSBEviJu4sFbNg3cdtBv3uhS w/WiPwH2hogVbf/b6iDia1cyJRDpUori9ZMo7QG9ntltvjfJGy0dRm8QXmq9r4LJg6FV 1UGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C9dE7tHKwWd+Q325ea3gyYmgSt9bZxfTUEi3V3Opfe0=; b=A3/lSVn+XdovbcSW2s9DBKTEJswuLgQYu9VXO2VFZ33X620tO86twxg95SB6mJ2YKr tGNBHpAoe8v8locp9C+at65Y/OZHs/uwBuHbXs+keDFzZrETEKuOtnp1M7oSDjFyKl/i zW4b3aksHco+LlJ2wcCxibn+RSglot8/xlQIe/CGEDh3YUrNKQ6FcrhAtujPK+pla/W7 G6Zaejs4aKueCe2Z4GWzeSGLKP5F8LI/Oy3DTuL3jgvUXAl7+hKSrqZaIeNpvABVzge5 GEtKUeFlU9K4pIFDdfAA3DG6mL0HgLXL6+OEsDAWV+f8F1zhyiY0j8KlPIIhW7TxmxFw NHlQ== X-Gm-Message-State: ANoB5pmlJTVW0J62YGuNWQbVOvu30GNVg3xad3WtYlCiLWPoLUGhVD6F Y//bnY0fKUAsBaCfHNgEVTv7Fb0OAamJ5ZmTnP+8uBSJS4k= X-Google-Smtp-Source: AA0mqf51VCXY89vsifywsOgc9t7QCfg0z+6ign/ENaiIc7C1/7p6FIoeNXjYjvtmJUxB6QSaieGFPsfUyW0PvmLNwvk= X-Received: by 2002:a17:906:114a:b0:790:b74b:abf2 with SMTP id i10-20020a170906114a00b00790b74babf2mr20451764eja.634.1669138645224; Tue, 22 Nov 2022 09:37:25 -0800 (PST) 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 References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com> <6146841c-baef-134-dcd9-30db2d92732@macktronics.com> <21FB93B6-708F-4E69-B482-C7601C15394A@karels.net> In-Reply-To: <21FB93B6-708F-4E69-B482-C7601C15394A@karels.net> From: Warner Losh Date: Tue, 22 Nov 2022 10:37:14 -0700 Message-ID: Subject: Re: dmesg content lifetime To: Mike Karels Cc: Dan Mack , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000007a5c705ee12a0d7" X-Rspamd-Queue-Id: 4NGs070jTDz3hHR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000007a5c705ee12a0d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 22, 2022 at 8:49 AM Mike Karels wrote: > On 22 Nov 2022, at 9:34, Dan Mack wrote: > > > It disappears a piece at a time - the oldest entries disappear first. > However, it vanishes even when there are only 2-3 lines in it so I didn't > think capacity was in play as I expected. > > > > So for example I might see a rate-limit entry from someone spamming the > system and then it will usually be gone in a couple days and the buffer i= s > completely empty. Similarly if I do something like ifconfig em0 down; > ifconfig em0 up ; it's logged but disappears after a day or so. > > > > I'm looking to see if this is just a cron job or something clearing it > as it might be user-error on my part. Also this is an older system so > I'll probably look at it again after I update. > > I noticed this too, but discovered with =E2=80=9Cdmesg -a=E2=80=9D that t= he buffer was full > of syslog messages, so dmesg without -a showed nothing. > > It seems unfortunate that syslog messages logged in the message buffer, a= t > least once syslogd is running. Apparently this happens because they are > output to /dev/console. > Output to /dev/console that's not via syslogd goes into this buffer for syslogd to harvest and put in log files. IIRC, though, there's also the messages that syslogd sends to /dev/console in this buffer as well, which can be confusing. I'm not sure what a saner policy would be given both of these use cases. Warner Mike > > > Thank you, > > > > Dan > > > > > > On Tue, 22 Nov 2022, Warner Losh wrote: > > > >> On Tue, Nov 22, 2022 at 8:13 AM 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? > >>> > >> > >> It already is a fixed memory size. Do you see it all disappear at once= , > or > >> over time? > >> > >> Warner > >> > --00000000000007a5c705ee12a0d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Nov 22, 2022 at 8:49 AM Mike Karels <mike@karels.net> wrote:
On 22 Nov 2022, at 9:34, Da= n Mack wrote:

> It disappears a piece at a time - the oldest entries disappear first. = However, it vanishes even when there are only 2-3 lines in it so I didn'= ;t think capacity was in play as I expected.
>
> So for example I might see a rate-limit entry from someone spamming th= e system and then it will usually be gone in a couple days and the buffer i= s completely empty.=C2=A0 =C2=A0Similarly if I do something like ifconfig e= m0 down; ifconfig em0 up ; it's logged but disappears after a day or so= .
>
> I'm looking to see if this is just a cron job or something clearin= g it as it might be user-error on my part.=C2=A0 =C2=A0Also this is an olde= r system so I'll probably look at it again after I update.

I noticed this too, but discovered with =E2=80=9Cdmesg -a=E2=80=9D that the= buffer was full
of syslog messages, so dmesg without -a showed nothing.

It seems unfortunate that syslog messages logged in the message buffer, at<= br> least once syslogd is running.=C2=A0 Apparently this happens because they a= re
output to /dev/console.

Output to /dev/= console that's not via syslogd goes into this buffer for syslogd
<= div>to harvest and put in log files. IIRC, though, there's also the mes= sages that
syslogd sends to=C2=A0/dev/console in this buffer as w= ell, which can be confusing.
I'm not sure what a saner policy= would be given both of these use cases.

Warner

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mike

> Thank you,
>
> Dan
>
>
> On Tue, 22 Nov 2022, Warner Losh wrote:
>
>> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack <mack@macktronics.com> wrote: >>
>>> It seems like dmesg content ages out over time.=C2=A0 =C2=A0Is= there a way to leave
>>> the contents based on a fixed memory size instead?
>>>
>>
>> It already is a fixed memory size. Do you see it all disappear at = once, or
>> over time?
>>
>> Warner
>>
--00000000000007a5c705ee12a0d7--