Go to main content

Managing System Services in Oracle® Solaris 11.4

Exit Print View

Updated: Febuary 2019

Configuring Notification of State Transition and FMA Events

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 Event

The 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.

Example 22  Configuring Notification for Multiple State Events

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.com
Example 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:apache22 service transitions out of the online state.

$ svccfg -s http:apache22 setnotify from-online mailto:webservices@example.com
Example 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.com
Example 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