You can migrate services from RHEL to Oracle Solaris Service Management Facility (SMF) because SMF provides compatibility with legacy services. Legacy services include /etc/rc*.d, /etc/init.d, and /etc/inittab scripts, which are usually used in RHEL environments. Legacy services can continue to work as they did previously, and you can observe these services with SMF. However, to exploit all the advantages of SMF, such as self-healing capabilities or service restart, you need to convert the scripts to SMF manifests. For more information, see Service Manifests in Oracle Solaris.
SMF on Oracle Solaris 11 enables you to perform the following tasks through a single framework:
Observe and manage system-wide services
Provide consistent configuration handling
Automatically restart failed services in the appropriate order of dependency
Identify failed services
Securely delegate administrative tasks to non-root users
Preserve compatibility with legacy services
Automatically configure system administration jobs such as backup and restore
For more information about SMF, see Managing System Services in Oracle Solaris 11.3.
To increase system availability, the Fault Management Architecture (FMA) in Oracle Solaris helps you to detect system problems. For more information, see Fault Management Overview in Managing Faults, Defects, and Alerts in Oracle Solaris 11.3.
Information regarding services, service properties, property groups, and instances is stored in a service manifest file, /lib/svc/manifest, which is transferred to the SMF repository. SMF uses manifest information when managing services and when determining the root causes of service failures. The service manifest also describes the conditions under which failed services might be automatically restarted. A separate service manifest is required per service or application. Oracle Solaris provides some service manifests by default. Optionally, you can customize these manifests or write your own for other services. For more information, see Managing System Services in Oracle Solaris 11.3.
The following best practices can facilitate the migration of applications to the SMF and FMA framework:
Eliminate custom scripts that analyze application health and restart applications. SMF provides a simple way to encapsulate and standardize the methods used to start, stop, and restart applications.
Make applications SMF-aware early in the porting and testing process. Identify fault states and create a fault tree. Review error messages that are encountered and determine whether they can become FMA events.
Convert .rc and custom scripts to SMF profiles. Look for instances of start, stop, and check status methods.