NetBSD Problem Report #46488

From www@NetBSD.org  Sun May 27 16:53:46 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 6865563B88D
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 27 May 2012 16:53:46 +0000 (UTC)
Message-Id: <20120527165345.2CAAE63B882@www.NetBSD.org>
Date: Sun, 27 May 2012 16:53:45 +0000 (UTC)
From: randolf+netbsd.org@inter-corporate.com
Reply-To: randolf+netbsd.org@inter-corporate.com
To: gnats-bugs@NetBSD.org
Subject: Feature suggestion for "dmesg" output
X-Send-Pr-Version: www-1.0

>Number:         46488
>Category:       kern
>Synopsis:       Feature suggestion for "dmesg" output
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 27 16:55:00 +0000 2012
>Closed-Date:    Sat Dec 29 08:57:47 +0000 2018
>Last-Modified:  Sat Dec 29 08:57:47 +0000 2018
>Originator:     Randolf Richardson
>Release:        5.1.2
>Organization:
Inter-Corporate Computer & Network Services, Inc.
>Environment:
Not applicable
>Description:
When hard drive errors are reported in "dmesg" output, having a date and time stamp (in ISO format; "YYYYMMDDTHHMMSS") would be very helpful because sometimes users are physically swapping backup drives and it would make it easier to figure out which drive has a problem by comparing the dates and times with the entries they make on the log sheet (of when they swapped the drives).

I've had NetBSD servers that run for more than 1,000 days which include hard drive errors in the "dmesg" output where the users are rotating weekly or monthly between nearly one dozen different hard drives, and plugging in every drive to figure out which one has defects becomes a challenge because many of the drives are also cycled off-site.

Thanks in advance.

>How-To-Repeat:
Plug in an external USB hard drive that has bad sectors, then attempt to write data to those sectors -- a message is added to "dmesg" output (which is great) without a date/time stamp (which would be nice).

>Fix:
Not applicable.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46488: Feature suggestion for "dmesg" output
Date: Sun, 27 May 2012 19:29:46 +0200

 Aren't they logged (with timestamp) by syslogd in /var/log/messages (at
 least in the default configuration) as well?

 If log rotation gets in the way, you can configure it to a kernel only
 log and rotate that slower (or never).

 Martin

From: "Randolf Richardson" <randolf@inter-corporate.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46488: Feature suggestion for "dmesg" output
Date: Mon, 28 May 2012 05:13:22 -0700

 > The following reply was made to PR kern/46488; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/46488: Feature suggestion for "dmesg" output
 > Date: Sun, 27 May 2012 19:29:46 +0200
 > 
 >  Aren't they logged (with timestamp) by syslogd in /var/log/messages (at
 >  least in the default configuration) as well?
 >  
 >  If log rotation gets in the way, you can configure it to a kernel only
 >  log and rotate that slower (or never).

 	The problem with /var/log/messages is that a lot of things get 
 logged there and after months the old entries that are needed to 
 determine time/date of events are no longer available (due to the log 
 files being cycled out eventually) on high-volume systems.

 	Setting up a kernel-only log seems like a great solution (although 
 timestamps in dmesg output for errors that occur after the boot 
 process is complete would still be nice).  Which "man" page should I 
 read to find out more about configuring this?

 	Thanks.

 Randolf Richardson - randolf@inter-corporate.com
 Inter-Corporate Computer & Network Services, Inc.
 Beautiful British Columbia, Canada
 http://www.inter-corporate.com/


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46488: Feature suggestion for "dmesg" output
Date: Mon, 28 May 2012 14:16:27 +0200

 syslog.conf(5) explains this.

 Martin

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, randolf+netbsd.org@inter-corporate.com
Subject: re: kern/46488: Feature suggestion for "dmesg" output
Date: Wed, 30 May 2012 17:43:51 +1000

 >  >  Aren't they logged (with timestamp) by syslogd in /var/log/messages (at
 >  >  least in the default configuration) as well?
 >  >  
 >  >  If log rotation gets in the way, you can configure it to a kernel only
 >  >  log and rotate that slower (or never).
 >  
 >  	The problem with /var/log/messages is that a lot of things get 
 >  logged there and after months the old entries that are needed to 
 >  determine time/date of events are no longer available (due to the log 
 >  files being cycled out eventually) on high-volume systems.
 >  
 >  	Setting up a kernel-only log seems like a great solution (although 
 >  timestamps in dmesg output for errors that occur after the boot 
 >  process is complete would still be nice).  Which "man" page should I 
 >  read to find out more about configuring this?

 see /usr/share/examples/syslogd/all.debug.

 i wish we used this as a default, i love having each level have its
 own file etc.  also, i think in 2012 it's time to increase the
 default sizes.


 .mrg.

 ps: also see all.newsyslog.conf.

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: kern/46488: Feature suggestion for "dmesg" output
Date: Wed, 30 May 2012 17:45:05 +1000

 i have an in-progress change to add a timestamp to kernel messages
 as a sysctl option.  i'd like to see time stamps in the kernel
 messages themselves, beyond the syslogd ones.


 .mrg.

State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sat, 29 Dec 2018 08:57:47 +0000
State-Changed-Why:
dmesg messages have timestamps now, in -current.


>Unformatted:

Home	PR Database Search