The recent push of changeset ab9ae749152f
constitutes a heads-up for developers perfoming incremental
builds or who provoke frequent kernel panics. It's also a
heads-up if you look at crashdumps from other systems on your
up-to-date system. Finally: (a cutdown) fmd service now runs
in non-global zones.
Heads-up:
1) If performing an incremental nightly build (nightly -i) you may
see complaints regarding the following objects present in your
proto area not referenced in any package:
etc/net-snmp/snmp/fmd-trapgen.conf
usr/lib/fm/fmd/plugins/snmp-trapgen.so
usr/lib/fm/fmd/plugins/snmp-trapgen.conf
Manually remove the offending objects from your proto area, or
perform a full nightly build.
2) We bump DUMP_VERSION from 9 to 10 and PANICBUFVERS from 1 to 2.
This means you'll need matched kernel and userland bits for
savecore to be able to save a panic crash dump and for mdb to
understand the dump. This also means that mdb on a system
running these bits cannot open a dump from a system with
DUMP_VERSION 9. You'll see:
mdb: libkvm version (10) != corefile version (9)
You need to open such dumps from a system with matching libkvm
version, or use mdb.sfbay and script /mdb/bin/mdb which will
use binaries and libraries from a proto area matching the
build of the dump (apologies to external users).
3) The fault manager now "diagnoses" a defect on reboot after a
kernel panic. If you're in the habit of producing lots of
panics you may want to switch this off during development, as below.
4) svc:/system/fmd:default is now created in non-global zones.
This wad:
- Introduces email notifications for FMA events, using a new service
svc:/system/fm/smtp-notify:default delivered in an optional package
service/fault-management/smtp-notify
- Moves FMA SNMP trap functionality from an fmd module to an SMF service
svc:/system/fm/snmp-notify:default delivered in an optional package
service/fault-management/snmp-notify
- Allows snmp and/or email notification of SMF instance state
transitions (e.g., online to offline)
- Stores FMA and SMF notification preferences in the SMF
repository, and introduces svccfg {set,del,list}notify and svcs -n
to manage these preferences
- introduces the fmd service, with a reduced module list, in non-global
Solaris zones
- models SMF maintenance state within FMA with a corresponding defect
problem diagnosis
- models a kernel panic with a corresponding defect diagnosis; this
doesn't attempt any panic analysis, it is just collecting details
e.g. for automated call logging
The ARC cases present all the gory detail. Manpages can also be found
there until they're integrated into the next WOS build.
The last item has the potential to be a nuisance if you write kernel
and driver bugs for a living. You can disable the diagnosis of
panics by disabling the responsible module in fmd (which will also
disable SMF maintenance state diagnosis):
echo "setprop enable false" >> /usr/lib/fm/fmd/plugins/software-diagnosis.conf
Log bugs in fma/other, or a more-specific cat/subcat if you have narrowed
the cause.
Antonello Cruz - SMF: svc.startd, libscf, svccfg, svcs
Rob Johnston - Notification services & libfmnotify
Chris Beal - Panic diagnosis in fmd
Gavin Maltby - SMF maintenance defect in fmd; fmd in zones
--
Gavin Maltby
Oracle Corporation - Open Storage Systems
_______________________________________________
on-discuss mailing list
on-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/on-discuss
