The Strange New World of the SolarisTM 10 Service Management Facility
Peter Baer Galvin
Solaris 10 has many new and innovative features. The Service Management Facility,
however, is particularly different from previous Solaris releases and is core
to systems administration, so it deserves some scrutiny and attention. The first
hint that you are in a new world is a glance at the /etc/rc* directories. The
next clue is that killing a process such as sendmail no longer works. Where
are we and why are we here? Let's take a look at the Solaris 10 Service Management
Facility (SMF).
The Problem
Before the advent of SMF, a booting Solaris system ran the init daemon,
which parsed the /etc/inittab file, which fired off a series of run control
(rc) scripts, depending on the run level the system was trying to attain. The
default run level was "3", multi-user mode with networking. The inetd
daemon spawned other daemons, as necessary, to provide network services. And
all was good. Or was it?
Life with init, rc scripts, and inetd was less than pleasant.
To change the parameters of a daemon, for example, you had to determine where
the daemon was started and figure out how to change the parameters associated
with the start method. Changing an rc script was fraught with peril -- one false
move, and the system would fail to boot properly or even hang during booting.
Testing the rc script change meant rebooting the system. Debugging problems
with rc scripts meant turning on debugging options (such as adding set -x
to the script) and rebooting, perhaps multiple times as fixes were tried. Consider
also that the system booted inefficiently because it marched through the rc
scripts sequentially, even if some of the activities would have worked correctly
if done in parallel.
|
