Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Common Tasks Oracle Solaris 11 Information Library |
1. Locating Information About Oracle Solaris Commands
2. Managing User Accounts and Groups (Overview)
3. Managing User Accounts and Groups (Tasks)
4. Booting and Shutting Down an Oracle Solaris System
5. Working With Oracle Configuration Manager
6. Managing Services (Overview)
Service Configuration Repository
SMF Administrative and Programming Interfaces
SMF Command-Line Administrative Utilities
Service Management Configuration Library Interfaces
Managing Information in the Service Configuration Repository
When to Use Run Levels or Milestones
Determining a System's Run Level
What Happens When the System Is Brought to Run Level 3
9. Managing System Information (Tasks)
10. Managing System Processes (Tasks)
11. Monitoring System Performance (Tasks)
12. Managing Software Packages (Tasks)
14. Scheduling System Tasks (Tasks)
15. Setting Up and Administering Printers by Using CUPS (Tasks)
16. Managing the System Console, Terminal Devices, and Power Services (Tasks)
17. Managing System Crash Information (Tasks)
18. Managing Core Files (Tasks)
19. Troubleshooting System and Software Problems (Tasks)
20. Troubleshooting Miscellaneous System and Software Problems (Tasks)
SMF includes a master restarter daemon and delegated restarters. In addition, each service or service instance can store configuration data in properties. These properties are organized into property groups to make administration simpler.
The svc.startd daemon is the master process starter and restarter. The daemon is responsible for managing service dependencies for the entire system. The daemon takes on the previous responsibility that init held of starting the appropriate /etc/rc*.d scripts at the appropriate run levels. First, svc.startd retrieves the information in the service configuration repository. Next, the daemon starts services when their dependencies are met. The daemon is also responsible for restarting services that have failed and for shutting down services whose dependencies are no longer satisfied. The daemon uses operating system events, such as process death, to keep track of service states.
Some services have a set of common behaviors on startup. To provide commonality among these services, a delegated restarter might take responsibility for these services. In addition, a delegated restarter can be used to provide more complex or application-specific restarting behavior. The delegated restarter can support a different set of methods, but exports the same service states as the master restarter. The restarter's name is stored with the service. A current example of a delegated restarter is inetd, which can start Internet services on demand, rather than having the services always running. The defined restarter for each service can be displayed using the svcs -l command.
All information in the service configuration repository is stored as a set of properties, which are grouped by property groups. Property groups are used to group different types of service information. Some of the common property groups include:
general – Contains information about the service instance, including the general/enabled property, which defines whether the instance is enabled
restarter – Contains runtime information that is stored by the service's restarter, including the restarter/state property, which shows the current state of the service
start – Contains the start method definition, including the start/exec property, which defines what program to execute to start the service
The system defines many other property groups. Services can also define their own property groups in order to store service-specific configuration information. Another common property group is config, although others are common as well. See the smf(5) man page for more information about properties and property groups.