I notice that some syslog messages seem to append some type of ID field
to the daemon field of the log entry:

Jan 17 08:03:46 file-0202 genunix: [ID 408789 kern.notice] NOTICE: ce0:
fault cleared external to device; service available
Jan 17 08:03:46 file-0202 genunix: [ID 451854 kern.notice] NOTICE: ce0:
xcvr addr:0x01 - link up 1000 Mbps full duplex
Jan 17 08:03:46 file-0202 genunix: [ID 408789 kern.notice] NOTICE: ce1:
fault cleared external to device; service available
Jan 17 08:03:46 file-0202 genunix: [ID 451854 kern.notice] NOTICE: ce1:
xcvr addr:0x01 - link up 1000 Mbps full duplex

Is it possible to disable or change this behavior? I centralize all my
logs to a standard syslog box and then parse them into a database.
However the solaris log entries differ from my SuSE, Red Hat, Irix, and
other various systems.

Thx,
cc

Rhugga wrote:
> I notice that some syslog messages seem to append some type of ID field
> to the daemon field of the log entry:
>
> Jan 17 08:03:46 file-0202 genunix: [ID 408789 kern.notice] NOTICE: ce0:
> fault cleared external to device; service available
> Jan 17 08:03:46 file-0202 genunix: [ID 451854 kern.notice] NOTICE: ce0:
> xcvr addr:0x01 - link up 1000 Mbps full duplex
> Jan 17 08:03:46 file-0202 genunix: [ID 408789 kern.notice] NOTICE: ce1:
> fault cleared external to device; service available
> Jan 17 08:03:46 file-0202 genunix: [ID 451854 kern.notice] NOTICE: ce1:
> xcvr addr:0x01 - link up 1000 Mbps full duplex
>
> Is it possible to disable or change this behavior? I centralize all my
> logs to a standard syslog box and then parse them into a database.
> However the solaris log entries differ from my SuSE, Red Hat, Irix, and
> other various systems.
>
> Thx,
> cc
>

edit /kernel/drv/log.conf and stick a "msgid=0;" after the "instance=0;"

You'll have to reboot.

Thanks.

reboot ugh. System has 400 days of uptime, heh, reboot might not work.
Any possible jerry-rig work-arounds?

Thx,
cc

Rhugga wrote:
> Thanks.
>
> reboot ugh. System has 400 days of uptime, heh, reboot might not work.
> Any possible jerry-rig work-arounds?
>
> Thx,
> cc
>

update_drv any use?

Me wrote:
> Rhugga wrote:
>
>> Thanks.
>>
>> reboot ugh. System has 400 days of uptime, heh, reboot might not work.
>> Any possible jerry-rig work-arounds?
>>
>> Thx,
>> cc
>>
>
> update_drv any use?

Meant to add, full command would be "update_drv -f log"

Well, I added the following to log.conf:

#
# Copyright (c) 1992, by Sun Microsystems, Inc.
#
#ident "@(#)log.conf 1.4 93/06/03 SMI"

name="log" parent="pseudo" instance=0 msgid=0;

Executed update_drv -f log and log entries are still getting the
message ID embedded.

So am I needing a reboot or is it possible this is the wrong solution?
Thx,
cc

Rhugga wrote:
> Well, I added the following to log.conf:
>
> #
> # Copyright (c) 1992, by Sun Microsystems, Inc.
> #
> #ident "@(#)log.conf 1.4 93/06/03 SMI"
>
> name="log" parent="pseudo" instance=0 msgid=0;
>
> Executed update_drv -f log and log entries are still getting the
> message ID embedded.
>
> So am I needing a reboot or is it possible this is the wrong solution?
> Thx,
> cc
>

Just reboot the beast. While you may loose your uptime at least it's
not a window$ box. Chances are better than not that it will actually
come back up ;-).

Well, yea Sun confirmed a reboot is required but they also said that
setting msgid=0 has been unstable under certain configs and they don't
recommend doing it. (why something so trivial as injecting a message ID
into the message field could cause something to be unstable is beyond
me)

Also, this isn't just a single machine I'm talking about here, this
would mean a reboot of over 20 servers that each take about 2 works of
prep work to plan a reboot and then 2 more weeks of dealing with all
the whining scientists (aka: grown men) that can't deal with a 2-hour
(if that) 6AM Sunday morning downtime. =p
That for all the suggestions though.