You can configure the system to notify you when a service changes state or when an FMA event occurs. You can specify either Simple Mail Transfer Protocol (SMTP) or Simple Network Management Protocol (SNMP) notification.
SMF uses the system SNMP configuration. No SNMP configuration is required in SMF unless you want to change the default notification. By default, SNMP traps are sent on maintenance transitions. If you use SNMP for transition notification, you can configure additional traps for other state transitions. See the snmp-notify(8) man page for examples.
The following examples show how to set notification parameters for SMF and FMA events and how to delete notification parameters. If you receive a notification of a service in the maintenance, offline, or degraded state, use the svcs command to investigate, as described in Repairing an Instance That Is Degraded, Offline, or in Maintenance.
Example 21 Configuring a Global Notification for a Service State EventThe following command creates a notification that sends email when services go into the maintenance state.
$ svccfg setnotify -g to-maintenance mailto:sysadmins@example.com
The -g option sets this notification parameter for all service instances that do not have custom values set. All modified service instances are refreshed. The -g option can only be used when setting notification for service state transitions, not with FMA events.
The to-maintenance argument is a state transition event as described in “Notification Parameters” in the smf(7) man page. Specifying only the state name includes both to-state and from-state transitions. This event can also be a comma separated list of transitions.
The mailto argument specifies the notification you want to receive for the specified event. This argument could also specify snmp. An snmp notification value must be either snmp:active or snmp:inactive. A mailto notification value can be either mailto:active or mailto:inactive, in addition to the form shown in this example. Setting a notification parameter overwrites any existing value for that event. The active and inactive settings do not overwrite existing values but toggle whether the existing notification is in effect for the specified event.
This example notifies whenever the system shuts down, successfully boots, or fails to boot. The following command creates a notification that sends email when services transition into the online state, out of the online state, or into the maintenance state. Specifying online is equivalent to specifying both to-online and from-online.
$ svccfg setnotify -g online,to-maintenance mailto:sysadmins@example.comExample 23 Configuring a Notification for a Specified Service Instance
The following command creates a notification that sends email when the pkg/mirror service transitions into the maintenance state.
$ svccfg -s pkg/mirror setnotify to-maintenance mailto:installteam@example.com
The following command creates a notification that sends email when the http:apache24 service transitions out of the online state.
$ svccfg -s http:apache24 setnotify from-online mailto:webservices@example.comExample 24 Configuring a Notification for an FMA Event
The problem-diagnosed argument is an FMA event. This argument can be a comma separated list of FMA events. See the list of FMA events in “Notification Parameters” in the smf(7) man page.
$ svccfg setnotify problem-diagnosed mailto:IT@example.comExample 25 Deleting Notification Settings
The following commands delete the notification settings set in the previous examples.
$ svccfg delnotify -g to-maintenance $ svccfg -s pkg/mirror delnotify to-maintenance $ svccfg setnotify problem-diagnosed mailto:root@localhost