Re: dmesg content lifetime
On Wed, 23 Nov 2022 07:16:19 +0900 Tomoaki AOKI wrote: > On Tue, 22 Nov 2022 19:13:18 +0100 > Gary Jennejohn wrote: > > Or look at /var/run/dmesg.boot. It doesn't get overwritten. > > > > It may be overwritten on reboot. > And there are dmesg.[today|yesterday] on /var/log/, too. > Rotated daily. > Yes, it definitely does get overwritten on reboot. But at least its contents are stable between boots. -- Gary Jennejohn
Re: dmesg content lifetime
On Tue, 22 Nov 2022 19:13:18 +0100 Gary Jennejohn wrote: > On Wed, 23 Nov 2022 01:16:55 +0900 > Tomoaki AOKI wrote: > > > On Tue, 22 Nov 2022 09:47:10 -0600 (CST) > > Dan Mack wrote: > > > > > 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 > > > > Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg > > to live longer. For example, recommended value by iwlwifi team is > > 1146880. Much larger than default. > > > > Note that this is actually a tunable and can be set only on boot time. > > > > Or look at /var/run/dmesg.boot. It doesn't get overwritten. > > -- > Gary Jennejohn It may be overwritten on reboot. And there are dmesg.[today|yesterday] on /var/log/, too. Rotated daily. -- Tomoaki AOKI
Re: dmesg content lifetime
On Tue, 22 Nov 2022, Rodney W. Grimes 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 is 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 ?dmesg -a? 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 least once syslogd is running. Apparently this happens because they are output to /dev/console. Mike I very much dislike this behavior. I though that the kernel dmesg buffer was for kernel messages only and that I could always count on going there for any kernel messages about a problem that has occurred, expecting to see my boot time output if nothing had happened since boot. Now instead I am almost always greated with an empty buffer :-(. Rod It's been this way for as long as I can remember. Decades probably. Ted 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 -- Rod Grimes rgri...@freebsd.org
Re: dmesg content lifetime
> 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 is > > 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 ?dmesg -a? 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 > least once syslogd is running. Apparently this happens because they are > output to /dev/console. > > Mike I very much dislike this behavior. I though that the kernel dmesg buffer was for kernel messages only and that I could always count on going there for any kernel messages about a problem that has occurred, expecting to see my boot time output if nothing had happened since boot. Now instead I am almost always greated with an empty buffer :-(. Rod > > > 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 > >> > > > -- Rod Grimes rgri...@freebsd.org
Re: dmesg content lifetime
On Wed, 23 Nov 2022 01:16:55 +0900 Tomoaki AOKI wrote: > On Tue, 22 Nov 2022 09:47:10 -0600 (CST) > Dan Mack wrote: > > > 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 > > Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg > to live longer. For example, recommended value by iwlwifi team is > 1146880. Much larger than default. > > Note that this is actually a tunable and can be set only on boot time. > Or look at /var/run/dmesg.boot. It doesn't get overwritten. -- Gary Jennejohn
Re: dmesg content lifetime
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 is > 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 “dmesg -a” 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 > 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 > >> >
Re: dmesg content lifetime
On Tue, 22 Nov 2022 09:47:10 -0600 (CST) Dan Mack wrote: > 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 Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg to live longer. For example, recommended value by iwlwifi team is 1146880. Much larger than default. Note that this is actually a tunable and can be set only on boot time. -- Tomoaki AOKI
Re: dmesg content lifetime
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 is > 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 “dmesg -a” 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 least once syslogd is running. Apparently this happens because they are output to /dev/console. 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 >>
Re: dmesg content lifetime
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
Re: dmesg content lifetime
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 pgpERzqAOoi9r.pgp Description: Цифровая подпись OpenPGP
Re: dmesg content lifetime
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 is 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. 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
Re: dmesg content lifetime
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
