Some times it could be usefull to display only the last boot message (ie: when grep'ing). The attached patch modifies sys/kern/subr_prf.c and dmesg.c (and the also the manual). It adds a tag (---<<<BOOT>>>---) at the begining of each boot message (the tag macro is stored in sys/sys/msgbuf.h and could also be stored in /usr/include/msgbuf.h) dmesg.c is modified and has a new option: -o, which when it is specified, displays the full content of the message buffer, otherwise only the last message is displayed). This patch has been tested (by me :p) without any troubles on -CURRENT.
On Fri, Sep 27, 2002 at 08:36:52PM +0200, Aurélien Nephtali wrote: > > Some times it could be usefull to display only the last boot > message (ie: when grep'ing). The attached patch modifies > sys/kern/subr_prf.c and dmesg.c (and the also the manual). It > adds a tag (---<<<BOOT>>>---) at the begining of each boot > message (the tag macro is stored in sys/sys/msgbuf.h and could > also be stored in /usr/include/msgbuf.h) dmesg.c is modified > and has a new option: -o, which when it is specified, displays > the full content of the message buffer, otherwise only the last > message is displayed). This patch has been tested (by me :p) > without any troubles on -CURRENT. This was my propsed solution to this annoyance so I agree with it. :) I haven't had time to test and fully review this change so I asked Aurélien to put it in a PR in hopes that someone else will have to time to commit it or something similar. -- Brooks
On Fri, Sep 27, 2002 at 12:00:20PM -0700, Brooks Davis wrote: > The following reply was made to PR bin/43434; it has been noted by GNATS. > > From: Brooks Davis <brooks@one-eyed-alien.net> > To: =?iso-8859-1?Q?Aur=E9lien_Nephtali?= <aurelien.nephtali@wanadoo.fr> > Cc: FreeBSD-gnats-submit@FreeBSD.ORG > Subject: Re: bin/43434: New option to 'dmesg' which allow to display or not old boot messages > Date: Fri, 27 Sep 2002 11:57:28 -0700 > > On Fri, Sep 27, 2002 at 08:36:52PM +0200, Aurélien Nephtali wrote: > > > > Some times it could be usefull to display only the last boot > > message (ie: when grep'ing). The attached patch modifies > > sys/kern/subr_prf.c and dmesg.c (and the also the manual). It > > adds a tag (---<<<BOOT>>>---) at the begining of each boot > > message (the tag macro is stored in sys/sys/msgbuf.h and could > > also be stored in /usr/include/msgbuf.h) dmesg.c is modified > > and has a new option: -o, which when it is specified, displays > > the full content of the message buffer, otherwise only the last > > message is displayed). This patch has been tested (by me :p) > > without any troubles on -CURRENT. > > This was my propsed solution to this annoyance so I agree with it. :) I > haven't had time to test and fully review this change so I asked > Aurélien to put it in a PR in hopes that someone else will have to time > to commit it or something similar. > What's wrong with ``dmesg | tail -1''? Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
On Mon, Sep 30, 2002 at 09:53:43AM +0300, Ruslan Ermilov wrote: > On Fri, Sep 27, 2002 at 12:00:20PM -0700, Brooks Davis wrote: > > On Fri, Sep 27, 2002 at 08:36:52PM +0200, AurIlien Nephtali wrote: > > >=20 > > > Some times it could be usefull to display only the last boot > > > message (ie: when grep'ing). The attached patch modifies > > > sys/kern/subr_prf.c and dmesg.c (and the also the manual). It > > > adds a tag (---<<<BOOT>>>---) at the begining of each boot > > > message (the tag macro is stored in sys/sys/msgbuf.h and could > > > also be stored in /usr/include/msgbuf.h) dmesg.c is modified > > > and has a new option: -o, which when it is specified, displays > > > the full content of the message buffer, otherwise only the last > > > message is displayed). This patch has been tested (by me :p) > > > without any troubles on -CURRENT. > > =20 > > This was my propsed solution to this annoyance so I agree with it. :) = I > > haven't had time to test and fully review this change so I asked > > AurIlien to put it in a PR in hopes that someone else will have to time > > to commit it or something similar. > > =20 > What's wrong with ``dmesg | tail -1''? It does nothing like what this patch does? That just shows the last line of dmesg, this cause dmesg to only show messages from this boot unless you specificly ask for saved messages (assuming they exist). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
On Mon, Sep 30, 2002 at 10:04:07AM -0700, Brooks Davis wrote: > On Mon, Sep 30, 2002 at 09:53:43AM +0300, Ruslan Ermilov wrote: > > On Fri, Sep 27, 2002 at 12:00:20PM -0700, Brooks Davis wrote: > > > On Fri, Sep 27, 2002 at 08:36:52PM +0200, AurIlien Nephtali wrote: > > > > > > > > Some times it could be usefull to display only the last boot > > > > message (ie: when grep'ing). The attached patch modifies > > > > sys/kern/subr_prf.c and dmesg.c (and the also the manual). It > > > > adds a tag (---<<<BOOT>>>---) at the begining of each boot > > > > message (the tag macro is stored in sys/sys/msgbuf.h and could > > > > also be stored in /usr/include/msgbuf.h) dmesg.c is modified > > > > and has a new option: -o, which when it is specified, displays > > > > the full content of the message buffer, otherwise only the last > > > > message is displayed). This patch has been tested (by me :p) > > > > without any troubles on -CURRENT. > > > > > > This was my propsed solution to this annoyance so I agree with it. :) I > > > haven't had time to test and fully review this change so I asked > > > AurIlien to put it in a PR in hopes that someone else will have to time > > > to commit it or something similar. > > > > > What's wrong with ``dmesg | tail -1''? > > It does nothing like what this patch does? That just shows the last > line of dmesg, this cause dmesg to only show messages from this boot > unless you specificly ask for saved messages (assuming they exist). > Then this would be indeed a useful option. The "last boot message" did not sound to me like the "messages from the last boot". :-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
On Mon, 30 Sep 2002, Brooks Davis wrote: > On Mon, Sep 30, 2002 at 09:53:43AM +0300, Ruslan Ermilov wrote: > > On Fri, Sep 27, 2002 at 12:00:20PM -0700, Brooks Davis wrote: > > > On Fri, Sep 27, 2002 at 08:36:52PM +0200, AurIlien Nephtali wrote: > > > >=20 > > > > Some times it could be usefull to display only the last boot > > > > message (ie: when grep'ing). The attached patch modifies > > > > sys/kern/subr_prf.c and dmesg.c (and the also the manual). It > > > > adds a tag (---<<<BOOT>>>---) at the begining of each boot > > > > message (the tag macro is stored in sys/sys/msgbuf.h and could > > > > also be stored in /usr/include/msgbuf.h) dmesg.c is modified > > > > and has a new option: -o, which when it is specified, displays > > > > the full content of the message buffer, otherwise only the last > > > > message is displayed). This patch has been tested (by me :p) > > > > without any troubles on -CURRENT. > > > =20 > > > This was my propsed solution to this annoyance so I agree with it. :) = > I > > > haven't had time to test and fully review this change so I asked > > > AurIlien to put it in a PR in hopes that someone else will have to time > > > to commit it or something similar. > > > =20 > > What's wrong with ``dmesg | tail -1''? > > It does nothing like what this patch does? That just shows the last > line of dmesg, this cause dmesg to only show messages from this boot > unless you specificly ask for saved messages (assuming they exist). What's wrong with ``grep [-C] <magic> /var/log/messages'' then? :-) (except it doesn't handled rotated log files or races with newsyslog ...). It handles rotation a bit better than dmesg -- my message buffer gets rotated by debugging cruft and doesn't keep boot messages for long. Some magic would be required to find the last message without tags. Printing only the very last message doesn't seem very useful anyway. Lastness depends on an arbitrary descision about where the boot ends. Bruce
On Tue, 1 Oct 2002, Brooks Davis wrote: > On Tue, Oct 01, 2002 at 10:10:06AM -0700, Bruce Evans wrote: > > > > What's wrong with ``grep [-C] <magic> /var/log/messages'' then? :-) > > (except it doesn't handled rotated log files or races with newsyslog ...). > > > > 99+% of the time when a user types dmesg what they really want to see is: > > Copyright (c) 1992-2002 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD 5.0-CURRENT #2: Thu Sep 26 14:33:02 PDT 2002 > root@minya.sea.one-eyed-alien.net:/usr/obj/usr/src/sys/GENERIC > Preloaded elf kernel "/boot/kernel/kernel" at 0xc06ca000. > Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc06ca0a8. > ... > > For the _current_ boot. They couldn't care less about previous boots > unless they are looking for a message to diagnose a crash. Currently if > you don't have extra debugging stuff on and you don't generate a lot of > errors, you typicaly find boot messages repeated several times, especialy > in -stable. Thus you have to carefully scroll though the whole list to > find the current boot. This change makes dmesg do what the user wants, > but allows access to the previous messages in the unlikely event they > are needed. I see. The description in the PR is confusing -- it says that the last boot message is wanted, but actually the messages from the current boot are wanted. I think grep or an editor search is enough to find the start of the buffer. This can be automated, preferably not by hacking on dmesg, but I wouldn't mind adding a tag that is easy to search for and likely to be unique for each boot. The implementation has a buffer overrun in subr_prf.c (when msg_bufx is near the end of the buffer at init time) and some style bugs. Any tag should be written using an ordinary printf. Bruce
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
A commit references this bug: Author: kevans Date: Thu Aug 9 01:32:10 UTC 2018 New revision: 337518 URL: https://svnweb.freebsd.org/changeset/base/337518 Log: kern: Add a BOOT_TAG marker at the beginning of boot dmesg From the "newly licensed to drive" PR department, add a BOOT_TAG marker (by default, --<<BOOT>>--, to the beginning of each boot's dmesg. This makes it easier to do textproc magic to locate the start of each boot and, of particular interest to some, the dmesg of the current boot. The PR has a dmesg(8) component as well that I've opted not to include for the moment- it was the more contentious part of this PR. bde@ also made the statement that this boot tag should be written with an ordinary printf, which I've- for the moment- declined to change about this patch to keep it more transparent to observer of the boot process. PR: 43434 Submitted by: dak <aurelien.nephtali@wanadoo.fr> (basically rewritten) MFC after: maybe never Changes: head/sys/kern/subr_prf.c head/sys/sys/msgbuf.h
A commit references this bug: Author: kevans Date: Mon Aug 20 17:27:31 UTC 2018 New revision: 338109 URL: https://svnweb.freebsd.org/changeset/base/338109 Log: MFC boot tagging support: r337518, r337544-r337546, r337548, r337579-r337580, r337952 This is equivalent to what's in head, except the default is an empty boot tag string so that nothing gets output by default. r337518: kern: Add a BOOT_TAG marker at the beginning of boot dmesg From the "newly licensed to drive" PR department, add a BOOT_TAG marker (by default, --<<BOOT>>--, to the beginning of each boot's dmesg. This makes it easier to do textproc magic to locate the start of each boot and, of particular interest to some, the dmesg of the current boot. The PR has a dmesg(8) component as well that I've opted not to include for the moment- it was the more contentious part of this PR. bde@ also made the statement that this boot tag should be written with an ordinary printf, which I've- for the moment- declined to change about this patch to keep it more transparent to observer of the boot process. PR: 43434 Submitted by: dak <aurelien.nephtali@wanadoo.fr> (basically rewritten) r337544: msgbuf: Light detailing (const'ify and bool'itize) r337545: BOOT_TAG: Make a config(5) option, expose as sysctl and loader tunable BOOT_TAG lived shortly in sys/msgbuf.h, but this wasn't necessarily great for changing it or removing it. Move it into subr_prf.c and add options for it to opt_printf.h. One can specify both the BOOT_TAG and BOOT_TAG_SZ (really, size of the buffer that holds the BOOT_TAG). We expose it as kern.boot_tag and also add a loader tunable by the same name that we'll fetch upon initialization of the msgbuf. This allows for flexibility and also ensures that there's a consistent way to figure out the boot tag of the running kernel, rather than relying on headers to be in-sync. Prodded super-super-lightly by: imp r337546: subr_prf: Use "sizeof current_boot_tag" instead r337548: subr_prf: style(9) the sizeof Reported by: jkim, ian r337579: boot tagging: minor fixes msgbufinit may be called multiple times as we initialize the msgbuf into a progressively larger buffer. This doesn't happen as of now on head, but it may happen in the future and we generally support this. As such, only print the boot tag if we've just initialized the buffer for the first time. The boot tag also now has a newline appended to it for better visibility, and has been switched to a normal printf, by requesto f bde, after we've denoted that the msgbuf is mapped. r337580: subr_prf: remove think-o that had returned to local patch Reported by: cognet r337952: subr_prf: Don't write kern.boot_tag if it's empty This change allows one to set kern.boot_tag="" and not get a blank line preceding other boot messages. While this isn't super critical- blank lines are easy to filter out both mentally and in processing dmesg later- it allows for a mode of operation that matches previous behavior. I intend to MFC this whole series to stable/11 by the end of the month with boot_tag empty by default to make this effectively a nop in the stable branch. Changes: _U stable/11/ stable/11/sys/conf/NOTES stable/11/sys/conf/options stable/11/sys/kern/subr_msgbuf.c stable/11/sys/kern/subr_prf.c stable/11/sys/sys/msgbuf.h
Can this PR be closed now? Looks like the change has been committed.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
We have a boot marker now; closing this, any other enhancements can go elsewhere.