SMF is the core service management framework in Oracle Solaris. It controls how system and application services start, stop, restart, and interact with each other.
Before SMF (Solaris 8/9), services were controlled by rc scripts located in /etc/init.d and /etc/rc*.d. Those scripts did not track dependencies properly, had weak error handling, and could not automatically recover from failures.
SMF solves those problems by providing:
- Automatic startup during boot
- Intelligent dependency handling
- Automatic restart on failure
- Centralized configuration repository
- Integrated logging
- RBAC-based delegated administration
- Service state tracking
SMF is tightly integrated with the Solaris kernel and Service Management Facility daemon (svc.startd).
1. How SMF Works Internally
When the system boots:
- The kernel starts svc.startd
- svc.startd reads the service repository database
- It evaluates service dependencies
- Services are started in correct order
- If a service fails repeatedly, it goes into maintenance mode
All service configuration and state information is stored in:
/etc/svc/repository.db
This is a binary file — do not edit it manually.
2. Key SMF Components
Service
A managed unit (e.g., SSH, cron, filesystem).
Example:
svc:/network/ssh
Instance
A service can have multiple instances.
Example:
svc:/network/ssh:default
default is the instance name.
FMRI (Fault Management Resource Identifier)
Each service has a unique identifier:
svc:/category/service:instance
Example:
svc:/network/ssh:default
Manifest
XML file describing:
- Service name
- Start/stop methods
- Dependencies
- Property groups
- Restart policy
Locations:
/lib/svc/manifest/ (Oracle default manifests)
/etc/svc/manifest/ (Custom manifests)
Method Scripts
These are actual scripts executed to start/stop services.
Location:
/lib/svc/method/
Example:
/lib/svc/method/sshd
Repository
Stores:
Service configuration
Service state
Properties
Dependency data
Location:
/etc/svc/repository.db
3. SMF Service States Explained
| State | Meaning |
|---|---|
| online | Running normally |
| offline | Not running but no error |
| disabled | Intentionally disabled |
| maintenance | Failed repeatedly |
| degraded | Running but partially functional |
| uninitialized | Not started since boot |
| legacy_run | Old-style init.d service |
4. Service Dependency Model
SMF ensures services start in the correct order.
Dependency types:
require_all → All listed services must be online
require_any → At least one must be online
optional_all → Continue even if dependency fails
Example:
SSH depends on:
local filesystem
loopback network
Check dependencies:
# svcs -d network/ssh:default
Check reverse dependencies:
# svcs -D network/ssh:default
If a required dependency fails, the service moves to offline or maintenance.
5. Managing Services
Check Service Status
# svcs
Detailed error info:
# svcs -xv
Specific service:
# svcs -xv network/ssh:default
Enable Service
# svcadm enable network/ssh
Enable temporarily (until reboot):
# svcadm enable -t network/ssh
Disable Service
# svcadm disable network/ssh
Restart Service
# svcadm restart network/ssh
Refresh Service (reload configuration)
# svcadm refresh network/ssh
Used when configuration file changes.
6. Service Logs
Each service instance has its own log file:
/var/svc/log/
Example:
/var/svc/log/network-ssh:default.log
These logs show:
Why service failed
Exit codes
Dependency errors
Always check logs before restarting blindly.
7. Modifying Service Properties
SMF services contain property groups.
View properties:
# svccfg -s network/ssh listprop
Set property:
# svccfg -s network/ssh setprop sshd_config/PermitRootLogin = boolean: false
Apply changes:
# svcadm refresh network/ssh
8. Creating a Custom SMF Service
Steps:
Create method script in:
/lib/svc/method/
Create XML manifest in:
/etc/svc/manifest/
Import manifest:
# svccfg import /etc/svc/manifest/myservice.xml
Enable service:
# svcadm enable myservice
Validate manifest:
# svccfg validate myservice.xml
9. SMF Restart Behavior
SMF automatically restarts failed services.
Restart policies are defined in manifest:
restart_on = error
restart_on = refresh
restart_on = none
If service fails too many times in short interval, SMF places it into:
maintenance state
Clear maintenance:
# svcadm clear <service>
10. SMF and RBAC
Solaris uses Role-Based Access Control.
Instead of giving full root access, you can assign service management rights.
Assign profile:
# roleadd -P "Service Management" oracle
# usermod -R "Service Management" oracle
Check profiles:
# profiles oracle
This allows limited service control without full root privileges.
11. Repository Backup and Recovery
Backup repository:
# svccfg backup /var/svc/repository.db /backup/repository.db
Restore repository:
# svccfg restore /backup/repository.db
If repository gets corrupted during boot, Solaris automatically attempts recovery from:
/etc/svc/repository-boot
Never manually edit repository.db.
12. Legacy Services
Old /etc/init.d scripts still function.
They appear as:
legacy_run
Example:
# svcs -a | grep legacy
SMF wraps them but they lack full dependency features.
13. Boot Milestones
SMF organizes boot into milestones:
svc:/milestone/single-user
svc:/milestone/multi-user
svc:/milestone/multi-user-server
Check current milestone:
# svcs milestone
Change milestone:
# svcadm milestone multi-user
14. Troubleshooting Methodology
When a service fails:
Check status:
# svcs -xv <service>
Check log:
# cat /var/svc/log/<service>.log
Verify dependencies:
# svcs -d <service>
Check method script permissions
Clear maintenance:
# svcadm clear <service>
Restart:
# svcadm restart <service>
No comments:
Post a Comment