way to clear dmesg content (or add lines)

[Bill McNAMARA_1]

Hi all,

is there a way to clear the dmesg.. or add lines to it?

For example, here is a c file that'll create syslog warnings.

Is there any recommendation of how and what kind of problems go into these logs?

Later,
Bill

logsys.c

#include
#include "/usr/include/syslog.h"

/* man 3 syslog */
/* see /etc/syslog.conf for log redirection administration */
main()
{
syslog(LOG_INFO, "process > severity < message ");
syslog(LOG_INFO, "---------------- > ------------ < --------");
/* set the PID */
openlog("myprogram : pid >",LOG_PID|LOG_CONS|LOG_NDELAY, LOG_DAEMON);
syslog(LOG_ALERT, "> LOG_ALERT: < alert message");
syslog(LOG_EMERG, "> LOG_EMERG: < emergency message");
syslog(LOG_CRIT, "> LOG_CRIT: < critical message");
syslog(LOG_ERR, "> LOG_ERR: < error message");
syslog(LOG_WARNING, "> LOG_WARNING: < warning message");
syslog(LOG_NOTICE, "> LOG_NOTICE: < notice message");
syslog(LOG_INFO, "> LOG_INFO: < info message");
syslog(LOG_DEBUG, "> LOG_DEBUG: < debug message");
syslog(LOG_DEBUG, "> LOG_DEBUG: < debug message");
return 0;
}
~

[Alex Glennie]

Not sure Bill but the following may be worth a note .....

PHKL_25493
s700_800 11.11 syslog and console data handling improved
Document Information Table

Patch Name: PHKL_25493

Patch Description: s700_800 11.11 syslog and console data handling improved

Creation Date: 01/10/19

Post Date: 01/10/30

Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11

Products: N/A

Filesets:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP

Automatic Reboot?: Yes

Status: General Release

Critical: No

Category Tags:
defect_repair general_release

Path Name: /hp-ux_patches/s700_800/11.X/PHKL_25493

Symptoms:
PHKL_25493:
( SR: [8606196155/STARS-ACTIVE/English] CR:JAGad65359 )
Missing console and/or syslog data when vmunix tries to
print more than 4 kilobytes of information at boot time.
Possible side effects include:
* The console repeats 4k worth of data -- up to 16 times
* The "dmesg" command returns information that was
printed prior to the first vmunix entry in syslog.log
* Important boot time messages may be lost.

Defect Description:
PHKL_25493:
( SR: [8606196155/STARS-ACTIVE/English] CR:JAGad65359 )
The old system message buffer was too small, and several
defects appeared when it overflowed. (Having a large
number of IO devices could trigger a buffer overflow.)

Resolution:
1) Increased the size of the system message buffer.
2) Solved the defects by using a cleaner implementation.
3) Maintained full compatibility with dmesg.

11.00 equiv : PHKL_25352

[fg_1]

Bill

This has always been a bone of contention with me. Dmegs while it's useful also doesn't have a date/time stamp to say what's recent or not. The file has a time stamp on it but the contents do not, so you have to play detective and decipher what's recent and what's not.

I know this doesn't solve the question at hand but I just wanted to get this out there.

Thanks.

[James R. Ferguson]

Hi Bill:

If you create a crontab entry that runs every 10-minutes, and looks like:

/usr/sbin/dmesg - >> /var/adm/messages

...then you can capture diagnostic messages accumulated in the dmesg buffer.

Regards!

...JRF...

[Bill McNAMARA_1]

I was considering doing that James, and it is the best option so far,

I suppose I would write some kind of driver program (like at hp.com/go/developer) and add printfs (as described in the driver quick and dirty debugging) but it seems like a hell of a lot of work!

Bill

[Bill McNAMARA_1]

Sorry it's go/developers

or the direct link..

http://h21007.www2.hp.com/dspp/home/home_HomePage_IDX/1,1292,,00.html

[Darrell Allen]

Hi Bill,

I assumed you were questioning how to clear the system buffer dmesg uses. I dunno. But as far as logging goes and to add to James's suggestion:

date>>/var/adm/messages;/usr/sbin/dmesg - >>/var/adm/messages

At least you'd have some idea of when things happened although you should be getting a lot of date entries without anything from dmesg - but that's a good thing.

Darrell

[Frank Slootweg]

If you still have a problem/question, then can you please re-explain it, because I do not understand the problem/question.

As to your:

> I was considering doing that James, and it is the best option so far,

It is not only the best option, it is the only correct/documented option. See the dmesg(1M) manual page (and root's default crontab).

If you want to know *why* the system message buffer / dmesg work in this 'strange'/'difficult' way, then let me know and I will explain.

[Bill McNAMARA_1]

go for it Frank!

Later,
Bill

[Frank Slootweg]

Wow! It is over a month ago and you expect me to *remember* this stuff? :-)

Well, the system message buffer / dmesg work in this 'strange'/'difficult' way, because when the 'kernel', i.e. also the drivers, have a problem to report, they can not expect the disk, filesystem, etc. to work. So they know there is a problem, but can not, at least not directly, log it to a disk file. So instead, they report it in 'the system message buffer', which is a circular FIFO (first-in, first-out)part of main memory (RAM). They *also* (try to) report the error on the system console.

So now the kernel's/driver's job is done, but the user is probably still unaware (unless he has seen the message on the console).

The job of dmesg is to 'empty' the system message buffer to a logfile on this. Therefor dmesg keeps a copy of the old (i.e. previous dmesg run) content of the system message buffer in a disk file, compares the new content to it, and appends the difference to the logfile. See the dmesg(1M) manual page for details about this part.

So in short:
- 'kernel' problems are always reported in the system message buffer.
- If the console is functioning, they are also reported on the system console.
- If the filesystem, cron and dmesg are functioning (and dmesg is properly configured), dmesg will log the problems to the designated logfile.

"Elementary, dear Watson!" :-)