Intermediate System Administration for the Solaris 10 Operating Student Guide phần 6 pps

The entire boot process is described by five distinct phases: ● The boot PROM phase ● The boot programs phase ● The kernelinitialization phase ● The initphase ● The svc.startdphase Figur

Identifying Legacy Run Level Fundamentals

A run level is a system state, represented by a digit or letter, that definesthe services and resources that are currently available to users

Table 9-1 shows the eight run levels found in the Solaris OS

Table 9-1 Solaris OS Run Levels

Run

Level Milestone Function

s or S single-user Solaris OS single-user mode with critical file systems

mounted and accessible

1 The system is running in a single-user administrative state

with access to all available file systems

2 multi-user The system is supporting multiuser operations Multiple

users can access the system All system daemons arerunning except for the Network File System (NFS) serverand some other network resource server related daemons

3 multi-user-server The system is supporting multiuser operations and has NFS

resource sharing and other network resource serversavailable

5 A transitional run level in which the Solaris OS is shut down

and the system is powered off

6 A transitional run level in which the Solaris OS is shut down

and the system reboots to the default run level

Determining a System’s Current Run Level

To determine the current run level of a system, use the who -rcommand.Figure 9-4 shows output from the command

Figure 9-4 The System’s Current Run Level

Changing Run Levels

Run levels are sometimes referred to as initstates because theinit

command can be used to transition between run levels The init

command passes the required run level to svc.startd

You can use theinitcommand to manually initiate run-level transitions.You can also change run levels with the shutdown,halt,reboot, and

poweroffcommands In addition, the svcadmcommand, can be used tochange the run level that a system will boot to, by selecting the milestone

to achieve

Note – Prior to Solaris 10 OS, the init daemon was responsible forstarting and stopping system services Starting with Solaris 10 OS, thisrole is now the responsibility of the svc.startd daemon Theinit

daemon initializes stream modules, configures socket transport providers,sets up the system for a correct response to a power fail shutdown, andstarts the svc.startd daemon

# who -r

run level 3 Jun 9 08:30 3 0 S

Current run level

Current run level

Date and time of the last run

level change

Number of times at this run level

since the last reboot

Previous run level

Identifying the Phases of the Boot Process

In general, when a system is powered on, the PROM monitor runs a POSTprocedure that checks the hardware and memory on the system If noerrors are found, and the auto-boot?parameter is set totrue, thesystem begins the boot process

The entire boot process is described by five distinct phases:

● The boot PROM phase

● The boot programs phase

● The kernelinitialization phase

● The initphase

● The svc.startdphase

Figure 9-5 shows the phases of the boot process

PROM Runs POST Boot PROM phase

bootblk Loads Secondary Boot Program (ufsboot) ufsboot Loads kernel Boot programs phase

File /etc/system kernel Initializes Itself and Loads Modules kernel initialization phase

/etc/init init Starts the svc.startd process

init phase

bootLocatesboot-device bootReads bootblk bootLoads bootblk

kernel Reads Configuration

kernel Starts

Boot PROM Phase

The boot PROM performs the following steps during the first part of theboot sequence:

● The PROM runs the POST

The boot PROM firmware runs the POST to verify the system’shardware and memory It then begins its boot sequence upon

successful completion of the self-test diagnostics

● The PROM displays the system identification banner

The model type, processor type and speed, keyboard status, PROMrevision number, amount of installed random access memory

(RAM), NVRAM serial number, Ethernet address, and host ID aredisplayed

● The boot PROM determines the boot device by reading the PROMparameterboot-device

● The boot PROM reads the disk label located at Sector 0 on the

default boot device

● The boot PROM finds thebootprogram from the default boot deviceprogrammed into the PROM

The boot PROM program reads a system’s primary boot programcalledbootblk(located at Sectors 1 through 15) that contains aUNIX file system (UFS) file system reader (The bootblkprogram isplaced on the disk by theinstallbootcommand during systeminstallation.)

Thebootcommand loads thebootblkprogram from its location onthe boot device into memory

Boot Programs Phase

The following describes the boot programs phase:

● The bootblkprogram loads the secondary boot program, ufsboot,from the boot device into memory

The path toufsbootis recorded in the bootblkprogram, which isinstalled by theinstallbootcommand

● The ufsbootprogram locates and loads the appropriate two-part

kernel

The core of the kernel is two pieces of static code calledgenunix

and unix, wheregenunixis the platform-independent generic

kernelfile andunixis the platform-specifickernelfile

Whenufsbootloads these two files into memory, they are combined

to form the running kernel

On a system running in 64-bit mode, the two-partkernelis located

in the directory:

/platform/‘uname -m‘/kernel/sparcv9

Note – Solaris 10 for SPARC only runs on 64-bit systems.

Note – To determine the platform name (for example, the system

hardware class), type the uname -mcommand For example, when youtype this command on an Ultra 10 workstation, the console displays

sun4u

The following describes thekernelinitialization phase:

● The kernel reads its configuration file, called /etc/system

● The kernel initializes itself and begins loading modules

The kernel uses theufsbootcommand to load the files When it has

Note – The /etc/initfile is a symbolic link to /sbin/init.

The SunOS™ kernel is a small static core, consisting ofgenunixandunix

and many dynamically loadable kernel modules

Modules can consist of device drivers, binary files to support file systems,and streams, as well as other module types used for specific tasks withinthe system

The modules that make up the kernel typically reside in the directories

/kerneland /usr/kernel Platform-dependent modules reside in the

/platform/‘uname -m‘/kerneland /platform/‘uname -i‘/kernel

directories

The following describes the types of module subdirectories contained inthe /kernel,/usr/kernel,/platform/‘uname -m‘/kernel, or

/platform/‘uname -i‘/kerneldirectories:

● drv/sparcv9– Device drivers

● exec/sparcv9– Executable file formats

● fs/sparcv9– File system types, for example,ufs,nfs, andproc

● misc/sparcv9– Miscellaneous modules, for example, usb

● sched/sparcv9– Scheduling classes (process execution scheduling)

● strmod/sparcv9– Streams modules (generalized connection

between users and device drivers)

● sys/sparcv9– System calls (defined interfaces for applications touse)

The /kernel/drv/sparcv9directory contains all of the device driversthat are used for system boot The /usr/kernel/drv/sparcv9directory

is used for all other device drivers

Modules are loaded automatically as needed either at boot time or ondemand, if requested by an application When a module is no longer inuse, it might be unloaded on the basis that the memory it uses is neededfor another task

Upon initial or reconfiguration boot, the system does a self-test andchecks for all devices that are attached.

The advantage of this dynamic kernelarrangement is that the overallsize of thekernelis smaller, which makes more efficient use of memoryand allows for simpler modification and tuning Figure 9-6 shows thisarrangement

Figure 9-6 DynamickernelArrangement

Note – Thesparcv9CPU is the type of CPU that supports 64-bitprocessing

Caution – The Solaris OS builds the kernel based upon the size of the

system (memory, CPUs, and so on) In almost all cases, the performance ofthe default kernel that is built is quite adequate to handle most day to dayactivities on the system Any modifications should be made with extremecaution

In Memory

Static Core genunixunixDevice Driver Modules Streams Modules

Module Directories /kernel

/usr/kernel /platform/'uname -m'/kernel /platform/'uname -i'/kernel

Modifying the kernel’s behavior (or configuration) requires editing the

/etc/systemfile Altering this file allows you to modify the kernel’streatment of loadable modules as well as to modify kernel parameters forsome performance tuning

The ufsboot program contains a list of default loadable kernel modulesthat are loaded at boot time However, you can override this list by

modifying the /etc/systemfile to control which modules, as well aswhich parameters, are loaded

All changes to this file take effect after a reboot

The /etc/systemfile can explicitly control:

● The search path for default kernel modules to be loaded at boot time

● The root file system type and device

● The modules that are excluded from loading automatically at boottime

● The modules to be forcibly loaded at boot time, rather that at firstaccess

● The new values to override the default kernel parameter values

Note – Command lines must be 80 characters or less in length, and

comment lines must begin with an asterisk (*) and end with a newlinecharacter

The /etc/systemfile is divided into five distinct sections:

● moddir:Sets the search path for default loadable kernel modules You can listtogether multiple directories to search, delimited either by blankspaces or colons If the module is not found in the first directory, thesecond directory is searched, and so on

● root device and root file system configuration:

Sets the root file system type to the listed value The default is

rootfs:ufs.Sets the root device The default is the physical path name of thedevice on which the boot program resides The physical path name isplatform dependent and configuration dependent The following is

an example path:

rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a

● exclude:Does not allow the loadable kernel modules to be loaded duringkernel initialization, for example:

exclude: sys/shmsys

● forceload:Forces the kernel modules to be loaded during kernel initialization,for example:

forceload: drv/vx

The default action is to load a kernel module automatically when itsservices are first accessed during runtime by a user or an application

● set:Changes kernel parameters to modify the operation of the system,for example:

set maxusers=40

Editing the /etc/system File

Caution – Before you edit the /etc/systemfile, you should make abackup copy If you enter incorrect values in this file, the system mightnot be able to boot

The following example shows how to copy the original /etc/systemfile

to a backup file and then edit the /etc/systemfile

# cp /etc/system /etc/system.orig

# vi /etc/system

If a boot process fails because of an unusable /etc/systemfile, issue theinteractive boot command: boot -a When you are requested to enterthe name of the systemfile, type in the name of your backup system

file, or, alternatively, enter /dev/nullfor a null configuration file

ok boot -a

Enter filename [kernel/sparcv9/unix]: <Return>

Enter default directory for modules [/platform ]: <Return>

Name of system file [etc/system]: etc/system.orig - or - /dev/null

root filesystem type [ufs]: <Return>

Enter physical name of root device [/ ]: <Return>

(further boot messages omitted)

The init Phase

The next to the last phase of the boot process is the initphase Duringthis phase, theinitdaemon starts the svc.startddaemon that isresponsible for starting and stopping services as requested The

/sbin/initphase uses information stored in the/etc/inittabfile

The /etc/inittab File

Each line in the/etc/inittabfile contains the following four fields:

id:rstate:action:process

Table 9-2 describes the fields in aninittabentry

The following example shows the defaultinittabfile installed with theSolaris 10 OS The lines of output are described after the example:

Note – Message output fromrcscripts is directed to the/dev/msglog

file Prior to the Solaris 8 OS, all of these messages were written to the

Table 9-2 Fields in theinittabFile

id Two character identifier for the entryrstate Run levels to which this entry appliesaction Defines how the process listed should be run

For a description of the action keywords see

man inittab

process Defines the command to execute

Table 9-3 shows an explanation for each action keyword.

Information about additional actionkeywords is available in the

inittabman page.The following describes each of the lines in the

/etc/inittabfile in order:

1 Initializes the STREAMS modules used for communication services

2 Configures the socket transport providers for network connections

3 Initializes the svc.startddaemon for SMF

4 Describes a power fail shutdown

Table 9-3 The actionField Keywords

Keyword Explanation

sysinit Executes the process before theinit process tries to

access the console, for example, the console loginprompt Theinit process waits for completion of theprocess before it continues to read theinittab file

powerfail Executes the process only if theinitprocess receives a

power fail signal

The svc.startd Daemon

The svc.startddaemon is the master process starter and restarter forSMF This daemon takes on the role of starting the appropriate processesfor the achieved run level This was previously the responsibility of the

initprocess

The svc.startddaemon uses information in the repository todetermine the required milestone and then starts to process the manifestslocated in the/var/svc/manifestdirectory

The /var/svc/manifest/milestonedirectory contains ExtensibleMarkup Language (XML) files which describe the dependencies for thismilestone Recall that a milestone is made up of multiple SMF services.Files in the /var/svc/manifest/milestonedirectory:

These.xmlfiles might refer to other.xmlfiles in subdirectories below

/var/svc/manifestthat contain commands to run, such as:

● /sbin/rc2

● /lib/svc/method/fs-local

Controlling Legacy Boot Processes

The Solaris OS provides a series of Legacy scripts to stop and startprocesses typically associated with run levels or milestones

Each run level has an associated script located in the/sbindirectory, withsome scripts hard-linked to each other

The scripts are executed by the svc.startddaemon to set up variables,test conditions, and make calls to other scripts that start and stop

processes for that run level

The rc0,rc5, and rc6scripts are hard-linked to each other Notice thateach script is assigned the same inode number The following is anexample of the hard links:

# ls -li /sbin/rc*

2317 -rwxr r 3 root sys 1983 Dec 22 18:06 rc0

2318 -rwxr r 1 root sys 2242 Dec 22 18:06 rc1

2319 -rwxr r 1 root sys 2536 Dec 22 18:06 rc2

2320 -rwxr r 1 root sys 2567 Dec 22 18:06 rc3

2317 -rwxr r 3 root sys 1983 Dec 22 18:06 rc5

2317 -rwxr r 3 root sys 1983 Dec 22 18:06 rc6

2321 -rwxr r 1 root sys 5125 Dec 22 18:06 rcS

The Solaris OS provides the same series ofrcscripts in the/etcdirectoryfor backward compatibility These scripts are symbolic link files to the rc

scripts in the /sbindirectory The following example shows thisconnection:

# ls -l /etc/rc?

ls -l rc?

lrwxrwxrwx 1 root root 11 Oct 12 17:15 rc0 -> /sbin/rc0lrwxrwxrwx 1 root root 11 Oct 12 17:15 rc1 -> /sbin/rc1lrwxrwxrwx 1 root root 11 Oct 12 17:15 rc2 -> /sbin/rc2lrwxrwxrwx 1 root root 11 Oct 12 17:15 rc3 -> /sbin/rc3lrwxrwxrwx 1 root root 11 Oct 12 17:15 rc5 -> /sbin/rc5

Table 9-4 summarizes the tasks performed by each of the/sbinscripts.

Table 9-4 Run Control Scripts and Their Functions

Script Function

/sbin/rc0 Runs the/etc/rc0.d/K*scripts and the/etc/rc0.d/S*scripts to stop

system services and daemons

Start scripts should only perform fast system cleanup functions

/sbin/rc1 Runs the/etc/rc1.d/S* scripts to perform the following tasks:

• Stops system services and daemons

• Terminates certain running application processes

• Unmounts all remote file systems

/sbin/rc2 Runs the/etc/rc2.d/K* scripts and the/etc/rc2.d/S* scripts to start

certain application daemons

/sbin/rc3 Runs the/etc/rc3.d/K*scripts and the/etc/rc3.d/S*scripts to start

certain application daemons

Note: TheK scripts are not normally present in the/etc/rc3.d

directory, although if they were present, they would be run

/sbin/rc5

/sbin/rc6

Runs the/etc/rc0.d/K*scripts and then the/etc/rc0.d/S*scripts toperform the following tasks:

• Stops system services and daemons

• Starts scripts that should only perform fast system cleanup functions

/sbin/rcS Runs the/etc/rcS.d scripts to bring up the system to run level S, and

establish a minimal network

The /etc/rc # d Directories

The /etc/rc#.ddirectories contain scripts that start and stop systemprocesses for that run level

Figure 9-7 shows an example of /etc/rc#.ddirectories

Figure 9-7

The /etc/rc#.ddirectories, for example/etc/rc2.d, contain scripts tostart and stop processes for run level 2 The following output shows apartial list of these scripts

# ls -l /etc/rc2.d

total 130

-rwxr r 6 root sys 324 Dec 10 11:26 K03samba

-rwxr r 5 root sys 824 May 27 2004 K05appserv

(some output omitted)

-rwxr r 5 root sys 2329 Dec 11 08:52 S94ncalogd

-rwxr r 2 root sys 733 Dec 11 08:54 S98deallocate

-rwxr r 5 root sys 1023 Dec 11 08:53 S99audit

-rwxr r 5 root sys 2804 Dec 7 20:52 S99dtlogin

K##script S##script

K##script

etc /(root)

K##script S##script

S##script

Start Run Control Scripts

The /etc/rc#.dstart scripts are always run in the sort order shown bythelscommand The files that begin with Sare run to start a systemprocess These scripts are called by the appropriate/sbin/rc#and thisscript passes the argument “start” to them if their names do not end in

.sh There are no arguments passed to.shscripts These files have names

in the form of:

S##name-of-script

For example, theS99dtloginscript starts the graphical login process

Stop Run Control Scripts

The /etc/rc#.dstop scripts (also referred to as the kill scripts) arealways run in the sort order shown by the lscommand The files thatbegin with Kare run to stop or kill a system process These scripts arecalled by the appropriate/sbin/rc#, and this script passes the argument

“stop” to them if their names do not end in.sh.These files have names in the form of:

K##name-of-script

For example, theK03sambascript stops the Samba server

Note – File names that begin with a lowercasekorsare ignored, and arenot executed To disable a script, rename it with the appropriate lowercaseletter

The /etc/init.d Directory

Run control scripts are located in the /etc/init.ddirectory

The run control script /etc/init.d/sambais hard-linked to thecorresponding run control script/etc/rc3.d/S90samba, as shown by the

Stopping and Starting Services Using SMF

Commands

Listing Services With the svcs Command

The svcscommand is used to monitor SMF services It is useful forexamining the status of services, and for following the dependencyrelationship between services

It is also possible to examine the dependency relationships of servicesusing thesvcs command by using the -dand the-Doptions The-d

option shows what other services the named service is dependent on The

-Doption shows what other services depend on the named service

The following example shows what the service dependencies are for the

filesystem/local:defaultservice instance:

The following example shows what services the multi-user:default

milestone depends on, or requires to run:

The following example shows what other services depend on the

Changing Service States Using the svcadm Command

The svcadmcommand can be used to change the state of servicesmanaged by SMF For example, to verify the status of the cronservice:

# svcadm -v disable -t system/cron:default

svc:/system/cron:default temporarily disabled

Using svcs to Determine Why Services are Not

Running

Thesvcscommand can also be used to troubleshoot why services are notrunning

# svcs -x cron

svc:/system/cron:default (clock daemon (cron))

State: disabled since Fri Feb 25 15:05:47 2005

Reason: Temporarily disabled by an administrator

See: http://sun.com/msg/SMF-8000-1S

See: cron(1M)

See: crontab(1)

See: /var/svc/log/system-cron:default.log

Impact: This service is not running

The cronservice has been temporarily disabled by the administrator

Further information about the service can be found in the

/var/svc/log/system-cron:default.loglog file, and at

http://sun.com/msg/SMF-8000-1S

Manipulating Services That Are Not Managed by SMF

If the FMRI prefix for a service islrc, then that service is not currentlymanaged by SMF In order to start and stop the service without changingrun levels, the script associated with that service has to be run manually.The script to run a legacy service, non-SMF managed, is in /etc/init.d.For example, to stop and start the vold volume manager daemon:

Creating New Service Scripts

You can create new scripts to start and stop additional processes orservices to customize a system

For example, to eliminate the requirement for a manual start of a databaseserver, you could create a script to start the database server automaticallyafter the appropriate network services have started

You could then create another script to terminate this service and shutdown the database server before the network services are stopped

The correct procedure is to incorporate the new service into the SMF Thisprocedure can be quite complex The general steps required are detailed

in the following list:

● Determine the process for starting and stopping your service

● Establish a name for the service, and the category this service fallsinto

● Determine whether your service runs multiple instances

● Identify any dependency relationships between this service and anyother services

● If a script is required to start and stop the process, create the scriptand place it in a local directory such as/usr/local/svc/method

● Create a service manifest file for your service This file describes theservice and any dependency relationships Service manifests arepulled into the repository either by using thesvccfgcommand or

at boot time

● Incorporate the script into the SMF using the svccfgutility

The following displays an example:

# vi /usr/local/svc/method/newservice

#!/sbin/sh

#

# Copyright 2004 Sun Microsystems, Inc All rights reserved

# Use is subject to license terms

Copyright 2004 Sun Microsystems, Inc All rights reserved

Use is subject to license terms

ident "@(#)newservice.xml 1.2 04/09/13 SMI"

>

<service_bundle type=’manifest’ name=’OPTnew:newservice’>

<service

name=’site/newservice’

<property_group name=’startd’ type=’framework’>

<propval name=’duration’ type=’astring’ value=’transient’/>

Copyright 2004 Sun Microsystems, Inc All rights reserved.

Use is subject to license terms

ident "@(#)newservice.xml 1.2 04/09/13 SMI"

>

● The name of the service The type (manifest) indicates a simpleservice rather than a milestone, the package providing the service,and the service name

<service_bundle type=’manifest’ name=’OPTnew:newservice’>

● Service category, type, name, and version

<property_group name=’startd’ type=’framework’>

<propval name=’duration’ type=’astring’ value=’transient’/>

</property_group>

● How the service is started and stopped

● The second entry makes sure that your service is associated with themulti-user milestone and that the multi-user milestone requires thisservice.

● Creating the instance

<instance name=’default’ enabled=’true’ />

This is done by running thesvccfgutility:

It should also be possible to manipulate the service using svcadm

# svcadm -v disable site/newservice

Finally, you can observe that the multiuser milestone requires the

newservicein order to complete its requirements

Adding Scripts to Start and Stop Services Not Managed by SMF

To add run control scripts to start and stop a service not managed by SMF,create the script in the/etc/init.ddirectory and create links in theappropriate/etc/rc#.ddirectory for the run level in which the service is

to be started and stopped

The following procedure describes how to add a run control script:

1 Create the script in the/etc/init.ddirectory

# vi /etc/init.d/ filename

# chmod 744 /etc/init.d/ filename

# chgrp sys /etc/init.d/ filename

2 Create links to the appropriate /etc/init.ddirectory

3 Use thelscommand to verify that the script has links in theappropriate directories

# ls -li /etc/init.d/ filename

# ls -li /etc/rc #.d/S##filename

# ls -li /etc/rc #.d/K##filename

4 Test thefilename by performing the following commands:

# /etc/init.d/ filename start

Figure 9-8 shows the run-level transitions that occur during the process of

a system boot or shut down

Figure 9-8 Run-Level Transitions

exit

halt boot -s

boot reboot

Power Off Power On

Power On

Performing System Shutdown Procedures

You can shut down the Solaris OS to perform administration tasks ormaintenance activities if you are anticipating a power outage or if youneed to move the system to a new location

The Solaris OS requires a clean and orderly shutdown, which stopsprocesses, writes data in memory to disks, and unmounts file systems

Of course, the type of work you need to do while the system is shut downdetermines how the system is shut down and which command you use.The following describes the different types of system shutdowns

● Shut down the system to single-user mode

● Shut down the system to stop the Solaris OS, and display theok

prompt

● Shut down the system and turn off power

● Shut down the system and automaticallyrebootto multiuser mode

The commands available to therootuser for doing these types of systemshutdown procedures include:

● /sbin/init(using run levels S, 0, 1, 5, or 6)

● /usr/sbin/shutdown(using run levels S, 0, 1, 5, or 6)

Note – Theinitcommand accepts more arguments than those listedhere These arguments are not listed here because they are outside of thetopic of system shutdown procedures

The /usr/sbin/init Command

You use the initcommand to shut down, power off, or reboot a system

in a clean and orderly manner It informs the svc.startddaemon of thechange in runlevel svc.startd, achieves the appropriate milestone,and ultimately executes the rc0kill scripts However, this command doesnot warn logged-in users that the system is being shut down, and there is

no grace period

To shut down the system to single-user mode, use either run level S or 1

# init S

To shut down the system to stop the Solaris OS and display the ok

prompt, perform the command:

Theshutdowncommand is a script that invokes theinitdaemon to shutdown, power off, or reboot the system It executes the rc0kill scripts toshut down processes and applications gracefully But unlike the init

command, the shutdowncommand does the following:

● Notifies all logged-in users that the system is being shut down

● Delays the shutdown for 60 seconds by default

● Enables you to include an optional descriptive message to informyour users of what will transpire

The command format for the shutdown command is:

The -yoption pre-answers the final shutdown confirmation question sothat the command runs without your intervention.

The-g grace-periodallows you to change the number of seconds fromthe 60-second default

The-i init-statespecifies the run level that thesystemis to attain Bydefault, system state S is used

Note – If the shutdowncommand displays the error message:

“shutdown: ’i’ - unknown flag,” it indicates that the shell haslocated and executed the/usr/ucb/shutdowncommand Reissue thecommand using its full path (for example,/usr/sbin/shutdown), or setthePATHvariable to ensure /usr/sbincomes before /usr/ucb

To shut down the system to single-user mode, enter the shutdown

command without options

# shutdown

To shut down the system to stop the Solaris OS, and display theok

prompt, perform the command:

# shutdown -y -g120 -i6 “The system is being rebooted”

“Ungraceful” Shutdown Commands

The following commands perform an immediate system shutdown They

do not execute therc0kill scripts They do not notify logged-in users, andthere is no grace period

# halt

# poweroff

# reboot

Caution – These commands should be used with extreme caution, and

only when there is no other alternative

Setting the Default Boot-time Milestone

The svcadmcommand can be used to control the milestone the

svc.startddaemon meets on boot The default milestone if one is notspecified is “all” which is an abstract milestone where all system servicesare started

To ensure that thesvc.startddaemon meets the requirements of themulti-user-server milestone on the next reboot, use the followingcommand before rebooting:

# svcadm -v milestone -d multi-user-server:default

Valid options for default boot level using the svcadmcommand includethe following: