NAME

ifconfig - configure network interface parameters

SYNOPSIS

/sbin/ifconfig interface [ address_family ] [ address [ dest_address ] ] [ up ] [ down ] [ auto-revarp ] [ netmask mask ] [ broadcast address ] [ metric n ] [ mtu n ] [ trailers | -trailers ] [ private | -private ] [ arp | -arp ] [ plumb ] [ unplumb ]

/usr/sbin/ifconfig interface [ address_family ] [ address [ dest_address ] ] [ up ] [ down ] [ auto-revarp ] [ netmask mask ] [ broadcast address ] [ metric n ] [ mtu n ] [ trailers | -trailers ] [ private | -private ] [ arp | -arp ] [ plumb ] [ unplumb ]

AVAILABILITY

SUNWcsr

DESCRIPTION

ifconfig is used to assign an address to a network interface and/or to configure network interface parameters. ifconfig must be used at boot time to define the network address of each interface present on a machine; it may also be used at a later time to redefine an interface's address or other operating parameters. Used without options, ifconfig displays the current configuration for a network interface. If a protocol family is specified, ifconfig will report only the details specific to that protocol family. Only the super-user may modify the configuration of a network interface.

The interface parameter is a string of the form name unit, for example le0 or ie1. Three special interface names, -a ,-ad and -au, are reserved and refer to all or a subset of the interfaces in the system. If one of these interface names is given, the commands following it are applied to all of the interfaces that match:

-a

Apply the commands to all interfaces in the system.

-ad

Apply the commands to all ``down'' interfaces in the system.

-au

Apply the commands to all ``up'' interfaces in the system.

Since an interface may receive transmissions in differing protocols, each of which may require separate naming schemes, the parameters and addresses are interpreted according to the rules of some address family, specified by the address_family parameter. The address families currently supported are ether and inet. If no address family is specified, inet is assumed.

For the TCP/IP family (inet), the address is either a host name present in the host name data base (see hosts(4)) or in the Network Information Service (NIS) map hosts, or a TCP/IP address expressed in the Internet standard "dot notation". Typically, an Internet address specified in dot notation will consist of your system's network number and the machine's unique host number. A typical Internet address is 192.9.200.44 ,where 192.9.200 is the network number and 44 is the machine's host number.

For the ether address family, the address is an Ethernet address represented as x: x: x: x: x: xwhere x is a hexadecimal number between 0 and FF.

If the dest_address parameter is supplied in addition to the address parameter, it specifies the address of the correspondent on the other end of a point to point link.

OPTIONS

arp

Enable the use of the Address Resolution Protocol in mapping between network level addresses and link level addresses (default). This is currently implemented for mapping between TCP/IP

addresses and 10Mb/s Ethernet addresses.

-arp

Disable the use of the Address Resolution Protocol.

auto-revarp

Use the Reverse Address Resolution Protocol (RARP) to automatically acquire an address for this interface.

down

Mark an interface "down". When an interface is marked "down", the system will not attempt to transmit messages through that interface. If possible, the interface will be reset to disable reception as well. This action does not automatically disable routes using the interface.

plumb

Open the device associated with the interface name and setup the streams needed for TCP/IP to use the device. Before this is done the interface will not show up in the output of ifconfig -a .

unplumb

Destroy any streams associated with this device and close the device. After this command is executed the device name should not show up in the output of ifconfig -a .

private

Tells the in.routed routing daemon that the interface should not be advertised.

-private

Specify unadvertised interfaces.

trailers

This flag used to cause a non-standard encapsulation of inet packets on certain link levels. Drivers supplied with this release no longer use this flag, but it is ignored for compatibility.

-trailers

Disable the use of a "trailer" link level encapsulation.

up

Mark an interface "up". This happens automatically when setting the first address on an interface. The up option enables an interface after an ifconfig down, reinitializing the hardware.

broadcast address

(inet only.) Specify the address to use to represent broadcasts to the network. The default broadcast address is the address with a host part of all 1's. A + (plus sign) given for the broadcast value causes the broadcast address to be reset to a default appropriate for the (possibly new) address and netmask. Note: The arguments of ifconfig are interpreted left to right, and therefore

ifconfig -a netmask + broadcast +

and

ifconfig -a broadcast + netmask +

may result in different values being assigned for the interfaces' broadcast addresses.

metric n

Set the routing metric of the interface to n, default 0 . The routing metric is used by the routing protocol Higher metrics have the effect of making a route less favorable; metrics are counted as addition hops to the destination network or host.

mtu n

Set the maximum transmission unit of the interface to n. For many types of networks the mtu has an upper limit, for example, 1500 for Ethernet.

netmask mask

(inet only.) Specify how much of the address to reserve for subdividing networks into sub-networks. The mask includes the network part of the local address and the subnet part, which is taken from the host field of the address. The mask can be specified as a single hexadecimal number with a leading 0x, with a dot-notation address, or with a pseudo-network name listed in the network table networks(4). The mask contains 1's for the bit positions in the 32-bit address which are to be used for the network and subnet parts, and 0's for the host part. The mask should contain at least the standard network portion, and the subnet field should be contiguous with the network portion. If a `+' (plus sign) is given for the netmask value, the mask is looked up in the netmasks database using the interface network number as the key. Netmask data may be located in the local /etc/netmasks file, or the NIS or NIS+ netmasks.byaddr map. The system administrator may configure the source and lookup order in the netmasks database via the name service switch.

EXAMPLES

If your workstation is not attached to an Ethernet, the ie0 interface should be marked "down" as follows:

example% ifconfig ie0 down

To print out the addressing information for each interface, use the following command:

example% ifconfig -a

To reset each interface's broadcast address after the netmasks have been correctly set, use the next command:

        example% ifconfig -a broadcast +
To change the Ethernet address for interface ie0, use the following command:
        example% ifconfig le0 ether aa:1:2:3:4:5

FILES

/etc/netmasks

netmask data

SEE ALSO

in.routed(1M), netstat(1M), ethers(3N), hosts(4), netmasks(4), networks(4), nsswitch.conf(4), arp (7)

DIAGNOSTICS

Messages indicating the specified interface does not exist, the requested address is unknown, or the user is not privileged and tried to alter an interface's configuration.

NOTES

It is recommended that the names broadcast, down, private, trailers, up, and the other possible option names not be selected when choosing host names. Choosing anyone of these names as host names will cause bizarre problems that can be extremely difficult to diagnose.

Name

rmtab– remote mounted file system table

Synopsis

/etc/rmtab

Description

rmtab contains a table of filesystems that are remotely mounted by NFS clients. This file is maintained by mountd(1M), the mount daemon. The data in this file should be obtained only from mountd(1M) using the MOUNTPROC_DUMP remote procedure call.

The file contains a line of information for each remotely mounted filesystem. There are a number of lines of the form:

hostname:fsname

The mount daemon adds an entry for any client that successfully executes a mount request and deletes the appropriate entries for an unmount request.

Lines beginning with a hash (' #') are commented out. These lines are removed from the file by mountd(1M) when it first starts up. Stale entries may accumulate for clients that crash without sending an unmount request.

Files

/etc/rmtab

See Also

mountd(1M), showmount(1M) 

Name

newfs– construct a UFS file system

Synopsis

newfs [-NSBTv] [mkfs-options] raw-device

Description

newfs is a "friendly" front-end to the mkfs(1M) program for making UFS file systems on disk partitions. newfs calculates the appropriate parameters to use and calls mkfs.

If run interactively (that is, standard input is a tty), newfs prompts for confirmation before making the file system.

If the -N option is not specified and the inodes of the device are not randomized, newfs calls fsirand(1M).

You must be super-user or have appropriate write privileges to use this command, except when creating a UFS file system on a diskette. See EXAMPLES.

Creating a Multiterabyte UFS File System

Keep the following limitations in mind when creating a multiterabyte UFS file system:

• nbpi is set to 1 Mbyte unless you specifically set it higher. You cannot set nbpi lower than 1 Mbyte on a multiterabyte UFS file system.

• fragsize is set equal to bsize.

Options

The following options are supported:

-N

Print out the file system parameters that would be used to create the file system without actually creating the file system. fsirand(1M) is not called here.

-S

Sends to stdout a human-readable version of the superblock that would be used to create a filesystem with the specified configuration parameters.

-B

Sends to stdout a binary (machine-readable) version of the superblock that would be used to create a filesystem with the specified configuration parameters.

-T

Set the parameters of the file system to allow eventual growth to over a terabyte in total file system size. This option sets fragsize to be the same as bsize, and sets nbpi to 1 Mbyte, unless the -i option is used to make it even larger. If you use the -f or -i options to specify a fragsize or nbpi that is incompatible with this option, the user-supplied value of fragsize or nbpi is ignored.

-v

Verbose. newfs prints out its actions, including the parameters passed to mkfs.

mkfs-options

Options that override the default parameters are:

-a apc

The number of alternate sectors per cylinder to reserve for bad block replacement for SCSI devices only. The default is 0.

This option is not applicable for disks with EFI labels and is ignored.

-b bsize

The logical block size of the file system in bytes, either 4096 or 8192. The default is 8192. The sun4u architecture does not support the 4096 block size.

-c cgsize

The number of cylinders per cylinder group, ranging from 16 to 256. The default is calculated by dividing the number of sectors in the file system by the number of sectors in a gigabyte. Then, the result is multiplied by 32. The default value is always between 16 and 256.

mkfs can override this value. See mkfs_ufs(1M) for details.

This option is not applicable for disks with EFI labels and is ignored.

-C maxcontig

The maximum number of logical blocks, belonging to one file, that are allocated contiguously. The default is calculated as follows:

maxcontig = disk drive maximum transfer size / disk block size

If the disk drive's maximum transfer size cannot be determined, the default value for maxcontig is calculated from kernel parameters as follows:

If maxphys is less than ufs_maxmaxphys, which is typically 1 Mbyte, then maxcontig is set to maxphys. Otherwise, maxcontig is set to ufs_maxmaxphys.

You can set maxcontig to any positive integer value.

The actual value will be the lesser of what has been specified and what the hardware supports.

You can subsequently change this parameter by using tunefs(1M).

-d gap

Rotational delay. This option is obsolete in the Solaris 10 release. The value is always set to 0, regardless of the input value.

-f fragsize

The smallest amount of disk space in bytes that can be allocated to a file. fragsize must be a power of 2 divisor of bsize, where:

bsize / fragsize is 1, 2, 4, or 8.

This means that if the logical block size is 4096, legal values for fragsize are 512, 1024, 2048, and 4096. When the logical block size is 8192, legal values are 1024, 2048, 4096, and 8192. The default value is 1024.

For file systems greater than 1 terabyte or for file systems created with the -T option, fragsize is forced to match block size (bsize).

-i nbpi

The number of bytes per inode, which specifies the density of inodes in the file system. The number is divided into the total size of the file system to determine the number of inodes to create.

This value should reflect the expected average size of files in the file system. If fewer inodes are desired, a larger number should be used. To create more inodes, a smaller number should be given. The default for nbpi is as follows:

Disk size Density Less than 1GB 2048 Less than 2GB 4096 Less than 3GB 6144 3GB to 1 Tbyte 8192 Greater than 1 Tbyte or created with -T 1048576

The number of inodes can increase if the file system is expanded with the growfs command.

-m free

The minimum percentage of free space to maintain in the file system, between 0% and 99%, inclusively. This space is off-limits to users. Once the file system is filled to this threshold, only the super-user can continue writing to the file system.

The default is ((64 Mbytes/partition size) * 100), rounded down to the nearest integer and limited between 1% and 10%, inclusively.

This parameter can be subsequently changed using the tunefs(1M) command.

-n nrpos

The number of different rotational positions in which to divide a cylinder group. The default is 8.

This option is not applicable for disks with EFI labels and is ignored.

-o space | time

The file system can either be instructed to try to minimize the time spent allocating blocks, or to try to minimize the space fragmentation on the disk. The default is time.

This parameter can subsequently be changed with the tunefs(1M) command.

-r rpm

The rotational speed of the disk in revolutions per minute. The default is driver- or device-specific.

Note that you specify rpm for newfs and rps for mkfs.

This option is not applicable for disks with EFI labels and is ignored.

-s size

The size of the file system in sectors. The default is to use the entire partition.

-t ntrack

The number of tracks per cylinder on the disk. The default is taken from the disk label.

This option is not applicable for disks with EFI labels and is ignored.

Operands

The following operands are supported:

raw-device

The name of a raw special device residing in the /dev directory (for example, /dev/rdsk/c0t0d0s6) on which to create the file system.

Usage

See largefile(5) for the description of the behavior of newfs when encountering files greater than or equal to 2 Gbyte ( 2³¹ bytes).

Examples

---

Example 1 Displaying the Parameters for the Raw Special Device




The following example verbosely displays the parameters for the raw special device, c0t0d0s6. It does not actually create a new file system:

example# newfs -Nv /dev/rdsk/c0t0d0s6 mkfs -F ufs -o N /dev/rdsk/c0t0d0s6 1112940 54 15 8192 1024 16 10 60 2048 t 0 -1 8 /dev/rdsk/c0t0d0s6: 1112940 sectors in 1374 cylinders of 15 tracks, 54 sectors 569.8MB in 86 cyl groups (16 c/g, 6.64MB/g, 3072 i/g) super-block backups (for fsck -b #) at: 32, 13056, 26080, 39104, 52128, 65152, 78176, 91200, 104224, . . .

---

---

Example 2 Creating a UFS File System




The following example creates a UFS file system on a diskette that is managed by a volume manager that makes use of the mount point /vol.

example% newfs /vol/dev/aliases/floppy0 newfs: construct a new file system /vol/dev/aliases/floppy0: (y/n)? y /vol/dev/aliases/floppy0: 2880 sectors in 80 cylinders of 2 tracks, 18 sectors 1.4MB in 5 cyl groups (16 c/g, 0.28MB/g, 128 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 640, 1184, 1792, 2336, . . .

---

---

Example 3 Creating a UFS File System That Will Eventually Be Grown to a Multiterabyte UFS File System




The following example creates a UFS file system that will eventually be grown to a multiterabyte UFS file system.

This command creates a 800-Gbyte file system on the volume, /dev/md/rdsk/d99.

# newfs -T /dev/md/rdsk/d99 newfs: construct a new file system /dev/md/rdsk/d99: (y/n)? y /dev/md/rdsk/d99: 1677754368 sectors in 45512 cylinders of 144 tracks, 256 sectors 819216.0MB in 1821 cyl groups (25 c/g, 450.00MB/g, 448 i/g) . . .

Then, if you increase the volume size for this file system, you can use the growfs command to expand the file system. The file system is grown to 1.2 terabytes in this example:

# growfs -v /dev/md/rdsk/d99 /usr/lib/fs/ufs/mkfs -G /dev/md/rdsk/d99 2516631552 /dev/md/rdsk/d99: 2516631552 sectors in 68268 cylinders of 144 tracks, 256 sectors 1228824.0MB in 2731 cyl groups (25 c/g, 450.00MB/g, 448 i/g). . .

---

Exit Status

The following exit values are returned:

0

The operation was successful.

1, 10

Usage error or internal error. A message is output to STDERR explaining the error.

Other exit values may be returned by mkfs(1M), which is called by newfs.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

See Also

fsck(1M), fsck_ufs(1M), fsirand(1M), mkfs(1M), mkfs_ufs(1M), tunefs(1M), attributes(5), largefile(5), ufs(7FS)

Diagnostics

newfs: No such file or directory

The device specified does not exist, or a disk partition was not specified.

special: cannot open

You must write access to the device to use this command.

Name

metadb– create and delete replicas of the metadevice state database

Synopsis

/sbin/metadb  -h

/sbin/metadb  [-s setname]

/sbin/metadb  [-s setname] -a [-f] [-k system-file] mddbnn

/sbin/metadb  [-s setname] -a [-f] [-k system-file]
 [-c number] [-l length] slice...

/sbin/metadb  [-s setname] -d [-f] [-k system-file] mddbnn

/sbin/metadb  [-s setname] -d [-f] [-k system-file] slice...

/sbin/metadb  [-s setname] -i

/sbin/metadb  [-s setname] -p [-k system-file] [mddb.cf-file]

Description

The metadb command creates and deletes replicas of the metadevice state database. State database replicas can be created on dedicated slices, or on slices that will later become part of a simple metadevice (concatenation or stripe) or RAID5 metadevice. Do not place state database replicas on fabric-attached storage, SANs, or other storage that is not directly attached to the system and available at the same point in the boot process as traditional SCSI or IDE drives. See NOTES.

The metadevice state database contains the configuration of all metadevices and hot spare pools in the system. Additionally, the metadevice state database keeps track of the current state of metadevices and hot spare pools, and their components. Solaris Volume Manager automatically updates the metadevice state database when a configuration or state change occurs. A submirror failure is an example of a state change. Creating a new metadevice is an example of a configuration change.

The metadevice state database is actually a collection of multiple, replicated database copies. Each copy, referred to as a replica, is subject to strict consistency checking to ensure correctness.

Replicated databases have an inherent problem in determining which database has valid and correct data. To solve this problem, Volume Manager uses a majority consensus algorithm. This algorithm requires that a majority of the database replicas be available before any of them are declared valid. This algorithm strongly encourages the presence of at least three initial replicas, which you create. A consensus can then be reached as long as at least two of the three replicas are available. If there is only one replica and the system crashes, it is possible that all metadevice configuration data can be lost.

The majority consensus algorithm is conservative in the sense that it will fail if a majority consensus cannot be reached, even if one replica actually does contain the most up-to-date data. This approach guarantees that stale data will not be accidentally used, regardless of the failure scenario. The majority consensus algorithm accounts for the following: the system will stay running with exactly half or more replicas; the system will panic when less than half the replicas are available; the system will not reboot without one more than half the total replicas.

When used with no options, the metadb command gives a short form of the status of the metadevice state database. Use metadb -i for an explanation of the flags field in the output.

The initial state database is created using the metadb command with both the -a and -f options, followed by the slice where the replica is to reside. The -a option specifies that a replica (in this case, the initial) state database should be created. The -f option forces the creation to occur, even though a state database does not exist. (The -a and -f options should be used together only when no state databases exist.)

Additional replicas beyond those initially created can be added to the system. They contain the same information as the existing replicas, and help to prevent the loss of the configuration information. Loss of the configuration makes operation of the metadevices impossible. To create additional replicas, use the metadb -a command, followed by the name of the new slice(s) where the replicas will reside. All replicas that are located on the same slice must be created at the same time.

To delete all replicas that are located on the same slice, the metadb -d command is used, followed by the slice name.

When used with the -i option, metadb displays the status of the metadevice state databases. The status can change if a hardware failure occurs or when state databases have been added or deleted.

To fix a replica in an error state, delete the replica and add it back again.

The metadevice state database (mddb) also contains a list of the replica locations for this set (local or shared diskset).

The local set mddb can also contain host and drive information for each of the shared disksets of which this node is a member. Other than the diskset host and drive information stored in the local set mddb, the local and shared diskset mddbs are functionality identical.

The mddbs are written to during the resync of a mirror or during a component failure or configuration change. A configuration change or failure can also occur on a single replica (removal of a mddb or a failed disk) and this causes the other replicas to be updated with this failure information.

Options

Root privileges are required for all of the following options except -h and -i.

The following options can be used with the metadb command. Not all the options are compatible on the same command line. Refer to the SYNOPSIS to see the supported use of the options.

-a

Attach a new database device. The /kernel/drv/md.conf file is automatically updated with the new information and the /etc/lvm/mddb.cf file is updated as well. An alternate way to create replicas is by defining them in the /etc/lvm/md.tab file and specifying the assigned name at the command line in the form, mddbnn, where nn is a two-digit number given to the replica definitions. Refer to the md.tab(4) man page for instructions on setting up replicas in that file.

-c number

Specifies the number of replicas to be placed on each device. The default number of replicas is 1.

-d

Deletes all replicas that are located on the specified slice. The /kernel/drv/md.conf file is automatically updated with the new information and the /etc/lvm/mddb.cf file is updated as well.

-f

The -f option is used to create the initial state database. It is also used to force the deletion of replicas below the minimum of one. (The -a and -f options should be used together only when no state databases exist.)

-h

Displays a usage message.

-i

Inquire about the status of the replicas. The output of the -i option includes characters in front of the device name that represent the status of the state database. Explanations of the characters are displayed following the replica status and are as follows:

d

replica does not have an associated device ID.

o

replica active prior to last mddb configuration change

u

replica is up to date

l

locator for this replica was read successfully

c

replica's location was in /etc/lvm/mddb.cf

p

replica's location was patched in kernel

m

replica is master, this is replica selected as input

r

replica does not have device relocation information

t

tagged data is associated with the replica

W

replica has device write errors

a

replica is active, commits are occurring to this

M

replica had problem with master blocks

D

replica had problem with data blocks

F

replica had format problems

S

replica is too small to hold current database

R

replica had device read errors

B

tagged data associated with the replica is not valid

-k system-file

Specifies the name of the kernel file where the replica information should be written. The default system-file is /kernel/drv/md.conf. This option is for use with the local diskset only.

-l length

Specifies the size of each replica. The default length is 8192 blocks, which should be appropriate for most configurations. "Replica sizes of less than 128 blocks are not recommended.

-p

Specifies updating the system file (/kernel/drv/md.conf) with entries from the /etc/lvm/mddb.cf file. This option is normally used to update a newly built system before it is booted for the first time. If the system has been built on a system other than the one where it will run, the location of the mddb.cf on the local machine can be passed as an argument. The system file to be updated can be changed using the -k option. This option is for use with the local diskset only.

-s setname

Specifies the name of the diskset on which the metadb command will work. Using the -s option will cause the command to perform its administrative function within the specified diskset. Without this option, the command will perform its function on local database replicas.

slice

Specifies the logical name of the physical slice (partition), such as /dev/dsk/c0t0d0s3.

Examples

---

Example 1 Creating Initial State Database Replicas




The following example creates the initial state database replicas on a new system.

# metadb -a -f c0t0d0s7 c0t1d0s3 c1t0d0s7 c1t1d0s3

The -a and -f options force the creation of the initial database and replicas. You could then create metadevices with these same slices, making efficient use of the system.

---

---

Example 2 Adding Two Replicas on Two New Disks




This example shows how to add two replicas on two new disks that have been connected to a system currently running Volume Manager.

# metadb -a c0t2d0s3 c1t1d0s3

---

---

Example 3 Deleting Two Replicas




This example shows how to delete two replicas from the system. Assume that replicas have been set up on /dev/dsk/c0t2d0s3 and /dev/dsk/c1t1d0s3.

# metadb -d c0t2d0s3 c1t1d0s3

Although you can delete all replicas, you should never do so while metadevices still exist. Removing all replicas causes existing metadevices to become inoperable.

---

Files

/etc/lvm/mddb.cf

Contains the location of each copy of the metadevice state database.

/etc/lvm/md.tab

Workspace file for metadevice database configuration.

/kernel/drv/md.conf

Contains database replica information for all metadevices on a system. Also contains Solaris Volume Manager configuration information.

Exit Status

The following exit values are returned:

0

successful completion

>0

an error occurred

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWmdr

See Also

mdmonitord(1M), metaclear(1M), metadetach(1M), metahs(1M), metainit(1M), metaoffline(1M), metaonline(1M), metaparam(1M), metarecover(1M), metarename(1M), metareplace(1M), metaroot(1M), metaset(1M), metassist(1M), metastat(1M), metasync(1M), metattach(1M), md.tab(4), md.cf(4), mddb.cf(4), md.tab(4), attributes(5), md(7D)

Solaris Volume Manager Administration Guide

Notes

Replicas cannot be stored on fabric-attached storage, SANs, or other storage that is not directly attached to the system. Replicas must be on storage that is available at the same point in the boot process as traditional SCSI or IDE drives. A replica can be stored on a:

• Dedicated local disk partition

• Local partition that will be part of a volume

• Local partition that will be part of a UFS logging device

Name

fssnap– create temporary snapshots of a file system

Synopsis

fssnap [-F FSType] [-V] -o special_options /mount/point

fssnap  -d [-F  FSType] [-V] /mount/point | dev

fssnap -i [-F FSType] [-V] [-o special_options] 
     [/mount/point | dev]

Description

The fssnap command creates a stable, read-only snapshot of a file system when given either an active mount point or a special device containing a mounted file system, as in the first form of the synopsis. A snapshot is a temporary image of a file system intended for backup operations.

While the snapshot file system is stable and consistent, an application updating files when the snapshot is created might leave these files in an internally inconsistent, truncated, or otherwise unusable state. In such a case, the snapshot will contain these partially written or corrupted files. It is a good idea to ensure active applications are suspended or checkpointed and their associated files are also consistent during snapshot creation.

File access times are not updated while the snapshot is being created.

A path to the virtual device that contains this snapshot is printed to standard output when a snapshot is created.

Options

The following options are supported:

-d

Deletes the snapshot associated with the given file system.

-F FSType

Specifies the file system type to be used. The FSType should either be specified here or be determined by matching the block special device with an entry in the /etc/vfstab table, or by consulting /etc/default/fs.

-i

Displays the state of any given FSType snapshot. If a mount-point or device is not given, a list of all snapshots on the system is displayed. When a mount-point or device is specified, detailed information is provided for the specified file system snapshot by default. The format and meaning of this information is file-system dependent. See the FSType-specific fssnap man page for details.

-o special_options

See the FSType-specific man page for fssnap.

-V

Echoes the complete command line, but does not execute the command.

Operands

The following operands are supported:

/mount/point

The directory where the file system resides.

Examples

See FSType-specific man pages for examples.

Exit Status

The following exit values are returned:

0

Successful completion.

>0

An error occurred.

Files

/etc/vfstab

Specifies file system type.

/etc/default/fs

Specifies the default local file system type.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

See Also

fssnap_ufs(1M), attributes(5)

Notes

This command might not be supported for all FSTypes.

Name

smf– service management facility

Description

The Solaris service management facility defines a programming model for providing persistently running applications called services. The facility also provides the infrastructure in which to run services. A service can represent a running application, the software state of a device, or a set of other services. Services are represented in the framework by service instance objects, which are children of service objects. Instance objects can inherit or override the configuration of the parent service object, which allows multiple service instances to share configuration information. All service and instance objects are contained in a scope that represents a collection of configuration information. The configuration of the local Solaris instance is called the “localhost” scope, and is the only currently supported scope.

Each service instance is named with a fault management resource identifier (FMRI) with the scheme “svc:”. For example, the syslogd(1M) daemon started at system startup is the default service instance named:

svc://localhost/system/system-log:default
svc:/system/system-log:default
system/system-log:default

In the above example, 'default' is the name of the instance and 'system/system-log' is the service name. Service names may comprise multiple components separated by slashes (/). All components, except the last, compose the category of the service. Site-specific services should be named with a category beginning with 'site'.

A service instance is either enabled or disabled. All services can be enabled or disabled with the svcadm(1M) command.

The list of managed service instances on a system can be displayed with the svcs(1) command.

Dependencies

Service instances may have dependencies on services or files. Those dependencies govern when the service is started and automatically stopped. When the dependencies of an enabled service are not satisfied, the service is kept in the offline state. When its dependencies are satisfied, the service is started. If the start is successful, the service is transitioned to the online state. Whether a dependency is satisfied is determined by its type:

require_all

Satisfied when all cited services are running (online or degraded), or when all indicated files are present.

require_any

Satisfied when one of the cited services is running (online or degraded), or when at least one of the indicated files is present.

optional_all

Satisfied if the cited services are running (online or degraded) or will not run without administrative action (disabled, maintenance, not present, or offline waiting for dependencies which will not start without administrative action).

exclude_all

Satisfied when all of the cited services are disabled, in the maintenance state, or when cited services or files are not present.

Once running (online or degraded), if a service cited by a require_all, require_any, or optional_all dependency is stopped or refreshed, the SMF considers why the service was stopped and the restart_on attribute of the dependency to decide whether to stop the service.

                   |  restart_on value
event              |  none  error restart refresh
-------------------+------------------------------
stop due to error  |  no    yes   yes     yes
non-error stop     |  no    no    yes     yes
refresh            |  no    no    no      yes

A service is considered to have stopped due to an error if the service has encountered a hardware error or a software error such as a core dump. For exclude_all dependencies, the service is stopped if the cited service is started and the restart_on attribute is not none.

The dependencies on a service can be listed with svcs(1) or svccfg(1M), and modified with svccfg(1M).

Restarters

Each service is managed by a restarter. The master restarter, svc.startd(1M) manages states for the entire set of service instances and their dependencies. The master restarter acts on behalf of its services and on delegated restarters that can provide specific execution environments for certain application classes. For instance, inetd(1M) is a delegated restarter that provides its service instances with an initial environment composed of a network connection as input and output file descriptors. Each instance delegated to inetd(1M) is in the online state. While the daemon of a particular instance might not be running, the instance is available to run.

As dependencies are satisfied when instances move to the online state, svc.startd(1M) invokes start methods of other instances or directs the delegated restarter to do so. These operations might overlap.

The current set of services and associated restarters can be examined using svcs(1). A description of the common configuration used by all restarters is given in smf_restarter(5).

Methods

Each service or service instance must define a set of methods that start, stop, and, optionally, refresh the service. See smf_method(5) for a more complete description of the method conventions for svc.startd(1M) and similar fork(2)-exec(2) restarters.

Administrative methods, such as for the capture of legacy configuration information into the repository, are discussed on the svccfg(1M) manual page.

The methods for a service can be listed and modified using the svccfg(1M) command.

States

Each service instance is always in a well-defined state based on its dependencies, the results of the execution of its methods, and its potential receipt of events from the contracts filesystem. The following states are defined:

UNINITIALIZED

This is the initial state for all service instances. Instances are moved to maintenance, offline, or a disabled state upon evaluation by svc.startd(1M) or the appropriate restarter.

OFFLINE

The instance is enabled, but not yet running or available to run. If restarter execution of the service start method or the equivalent method is successful, the instance moves to the online state. Failures might lead to a degraded or maintenance state. Administrative action can lead to the uninitialized state.

ONLINE

The instance is enabled and running or is available to run. The specific nature of the online state is application-model specific and is defined by the restarter responsible for the service instance. Online is the expected operating state for a properly configured service with all dependencies satisfied. Failures of the instance can lead to a degraded or maintenance state. Failures of services on which the instance depends can lead to offline or degraded states.

DEGRADED

The instance is enabled and running or available to run. The instance, however, is functioning at a limited capacity in comparison to normal operation. Failures of the instance can lead to the maintenance state. Failures of services on which the instance depends can lead to offline or degraded states. Restoration of capacity should result in a transition to the online state.

MAINTENANCE

The instance is enabled, but not able to run. Administrative action is required to restore the instance to offline and subsequent states. The maintenance state might be a temporarily reached state if an administrative operation is underway.

DISABLED

The instance is disabled. Enabling the service results in a transition to the offline state and eventually to the online state with all dependencies satisfied.

LEGACY-RUN

This state represents a legacy instance that is not managed by the service management facility. Instances in this state have been started at some point, but might or might not be running. Instances can only be observed using the facility and are not transferred into other states.

States can also have transitions that result in a return to the originating state.

Properties and Property Groups

The dependencies, methods, delegated restarter, and instance state mentioned above are represented as properties or property groups of the service or service instance. A service or service instance has an arbitrary number of property groups in which to store application data. Using property groups in this way allows the configuration of the application to derive the attributes that the repository provides for all data in the facility. The application can also use the appropriate subset of the service_bundle(4) DTD to represent its configuration data within the framework.

Property lookups are composed. If a property group-property combination is not found on the service instance, most commands and the high-level interfaces of libscf(3LIB) search for the same property group-property combination on the service that contains that instance. This feature allows common configuration among service instances to be shared. Composition can be viewed as an inheritance relationship between the service instance and its parent service.

Properties are protected from modification by unauthorized processes. See smf_security(5).

Snapshots

Historical data about each instance in the repository is maintained by the service management facility. This data is made available as read-only snapshots for administrative inspection and rollback. The following set of snapshot types might be available:

initial

Initial configuration of the instance created by the administrator or produced during package installation.

last_import

Configuration as prescribed by the manifest of the service that is taken during svccfg(1M) import operation. This snapshot provides a baseline for determining property customization.

previous

Current configuration captured when an administrative undo operation is performed.

running

The running configuration of the instance.

start

Configuration captured during a successful transition to the online state.

The svccfg(1M) command can be used to interact with snapshots.

Special Property Groups

Some property groups are marked as “non-persistent”. These groups are not backed up in snapshots and their content is cleared during system boot. Such groups generally hold an active program state which does not need to survive system restart.

Configuration Repository

The current state of each service instance, as well as the properties associated with services and service instances, is stored in a system repository managed by svc.configd(1M). This repository is transactional and able to provide previous versions of properties and property groups associated with each service or service instance.

The repository for service management facility data is managed by svc.configd(1M).

Service Bundles, Manifests, and Profiles

The information associated with a service or service instance that is stored in the configuration repository can be exported as XML-based files. Such XML files, known as service bundles, are portable and suitable for backup purposes. Service bundles are classified as one of the following types:

manifests

Files that contain the complete set of properties associated with a specific set of services or service instances.

profiles

Files that contain a set of service instances and values for the enabled property on each instance.

Service bundles can be imported or exported from a repository using the svccfg(1M) command. See service_bundle(4) for a description of the service bundle file format with guidelines for authoring service bundles.

A service archive is an XML file that contains the description and persistent properties of every service in the repository, excluding transient properties such as service state. This service archive is basically a 'svccfg export' for every service which is not limited to named services.

Legacy Startup Scripts

Startup programs in the /etc/rc?.d directories are executed as part of the corresponding run-level milestone:

/etc/rcS.d

milestone/single-user:default

/etc/rc2.d

milestone/multi-user:default

/etc/rc3.d

milestone/multi-user-server:default

Execution of each program is represented as a reduced-functionality service instance named by the program's path. These instances are held in a special legacy-run state.

These instances do not have an enabled property and, generally, cannot be manipulated with the svcadm(1M) command. No error diagnosis or restart is done for these programs.

See Also

svcs(1), inetd(1M), svcadm(1M), svccfg(1M), svc.configd(1M), svc.startd(1M), exec(2), fork(2), libscf(3LIB), strftime(3C), contract(4), service_bundle(4), user_attr(4), smf_bootstrap(5), smf_method(5), smf_restarter(5), smf_security(5)

Name

smc– start the Solaris Management Console

Synopsis

smc [ subcommand] [ args]

smc [ subcommand] [ args] -T tool_name 
     [ - - tool_args]

Description

The smc command starts the Solaris Management Console. The Solaris Management Console is a graphical user interface that provides access to Solaris system administration tools. It relies on Solaris Management Console servers running on one or more computers to perform modifications and report data. Each of these servers is a repository for code which the console can retrieve after the user of the console has authenticated himself or herself to the server.

The console can also retrieve toolboxes from the server. These toolboxes are descriptions of organized collections of tools available on that and possibly other servers. Once one of these toolboxes is loaded, the console will display it and the tools referenced in it.

The console can also run in a terminal (non-graphically), for use over remote connections or non-interactively from a script.

For information on the use of the graphical console, and for more detailed explanations of authentication, tools, and toolboxes, please refer to the Solaris Management Console online help available under the “Help” menu in the Solaris Management Console. To enable an NIS map to be managed from the Solaris Management Console, you must use the smc edit command to create a new toolbox for that map and enter the information about your NIS server where necessary. For instructions on creating a new toolbox, in the Solaris Management Console Help menu, select “Contents,” then “About the Solaris Management Console Editor,” then “To Create a Toolbox.”

Subcommands

The smc subcommands are:

open

The default subcommand for the Solaris Management Console is open. This will launch the console and allow you to run tools from the toolboxes you load. It does not need to be specified explicitly on the command line.

edit

The edit subcommand will also launch the console, like the open subcommand. However, after loading a toolbox, you will not be able to run the referenced tools. Instead, you will be able to edit that toolbox, that is, add, remove, or modify any tools or folders in that toolbox.

SMF Administration

The Solaris Management Console is implemented as a method that is managed by the service management facility (SMF) (see smf(5)), under the fault management resource identifier (FMRI):

svc:/application/management/wbem:default

Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M).

The configuration properties of this service can be modified with svccfg(1M).

Through svcadm, the Solaris Management Console supports the following actions:

start

Starts the CIM Object Manager (CIMOM) and Solaris Management Console server on the local host.

stop

Stops the CIMOM and Solaris Management Console server on the local host.

status

Gets the status of the CIMOM and Solaris Management Console server on the local host.

Controlling Remote Access

The Solaris Management Console supports an SMF property that controls remote access to WBEM-based applications, which include the Solaris Management Console. The property, options/tcp_listen, has default value of false, which disallows remote access. The value true allows remote access. See EXAMPLES.

Options

The following options are supported. These letter options can also be specified by their equivalent option words preceded by a double dash. For example, you can use either -D or - -domain with the domain argument.

If tool_args are specified, they must be preceded by the - - option and separated from the double dashes by a space.

- -auth-data 13;file

Specifies a file which the console can read to collect authentication data. When running the Solaris Management Console non-interactively, the console will still need to authenticate itself with the server to retrieve tools. This data can either be passed on the command line using the -u, -p, -r, and -l options (which is insecure, because any user can see this data), or it can be placed in a file for the console to read. For security reasons, this file should be readable only by the user running the console, although the console does not enforce this restriction.

The format of file is:

hostname=host name username=user name password=password for user name rolename=role name rolepassword=password for role name

Only one set of hostname-username-password-rolename-rolepassword may be specified in any one file. If the rolename is not specified, no role will be assumed.

-B | - -toolbox 13;toolbox

Loads the specified toolbox. toolbox can be either a fully-qualified URL or a filename. If you specify an HTTP URL as, for example,

http://host_name:port/. . .

it must point to a host_name and port on which an Solaris Management Console server is running. If you omit port, the default port, 898, is used. This option overrides the -H option.

-D | - -domain 13;domain

Specifies the default domain that you want to manage. The syntax of domain is type:/host_name/domain_name, where type is nis, dns, ldap, or file; host_name is the name of the machine that serves the domain; and domain_name is the name of the domain you want to manage. This option applies only to a single tool run in the terminal console.

If you do not specify this option, the Solaris Management Console assumes the file default domain on whatever server you choose to manage, meaning that changes are local to the server. Toolboxes can change the domain on a tool-by-tool basis; this option specifies the domain for all other tools.

-h | - -help

Prints a usage statement about the smc command and its subcommands to the terminal window. To print a usage statement for one of the subcommands, enter -h after the subcommand.

-H | - -hostname 13;host_name:port

Specifies the host_name and port to which you want to connect. If you do not specify a port, the system connects to the default port, 898. If you do not specify host_name:port, the Solaris Management Console connects to the local host on port 898. You may still have to choose a toolbox to load into the console. To override this behavior, use the -B option (see above), or set your console preferences to load a “home toolbox” by default.

-Jjava_option

Specifies an option that can be passed directly to the Java runtime (see java(1). Do not enter a space between -J and the argument. This option is most useful for developers.

-l | - -rolepassword 13;role_password

Specifies the password for the role_name. If you specify a role_name but do not specify a role_password, the system prompts you to supply a role_password. Passwords specified on the command line can be seen by any user on the system, hence this option is considered insecure.

-p | - -password 13;password

Specifies the password for the user_name. If you do not specify a password, the system prompts you for one. Passwords specified on the command line can be seen by any user on the system, hence this option is considered insecure.

-r | - -rolename 13;role_name

Specifies a role name for authentication. If you are running the Solaris Management Console in a terminal and you do not specify this option, no role is assumed. The GUI console may prompt you for a role name, although you may not need to assume a role.

-s | - -silent

Disables informational messages printed to the terminal.

-t

Runs the Solaris Management Console in terminal mode. If this option is not given, the Solaris Management Console will automatically run in terminal mode if it cannot find a graphical display.

- -trust

Trusts all downloaded code implicitly. Use this option when running the terminal console non-interactively and you cannot let the console wait for user input.

-T | - -tool 13;tool_name

Runs the tool with the Java class name that corresponds to tool_name. If you do not specify this option and the Solaris Management Console is running in terminal mode, the system prompts you. If the Solaris Management Console is running in graphical mode, the system either loads a toolbox or prompts you for one (see options -H and -B).

-u | - -username 13;user_name

Specifies the user name for authentication. If you do not specify this option, the user identity running the console process is assumed.

-v | - -version

Prints the version of the Solaris Management Console to the terminal. In the graphical console, this information can be found in the About box, available from the Help menu.

-y | - -yes

Answers yes to all yes/no questions. Use this option when running the terminal console non-interactively and you cannot let the console wait for user input.

Examples

---

Example 1 Printing a Usage Statement




The following prints a usage statement about the smc command to the terminal window:

smc --help

---

---

Example 2 Using SMF Property to Allow Remote Access




The following sequence of commands allows remote access to WBEM-based applications, including the Solaris Management Console.

# svccfg -s svc:/application/management/wbem \ setprop options/tcp_listen = true # svcadm refresh svc:/application/management/wbem

---

---

Example 3 Passing an Option to Java




The following passes an option through to the Java VM, which sets the com.example.boolean system property to true. This system property is only an example; the Solaris Management Console does not use it.

smc -J-Dcom.example.boolean=true

---

Environment Variables

See environ(5) for a description of the following environment variable that affects the execution of the smc command:

JAVA_HOME

If you do not specify this environment variable, your PATH is searched for a suitable java. Otherwise, the /usr/j2se location is used.

Exit Status

The following exit values are returned. Other error codes may be returned if you specify a tool (using -T tool_name) that has its own error codes. See the documentation for the appropriate tool.

0

Successful completion.

1

An error occurred.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWmcc

See Also

auths(1), java(1), profiles(1), roles(1), smcconf(1M), svcadm(1M), svccfg(1M), attributes(5), environ(5), smf(5), X(7)

http://dlc.sun.com/zip/47.16.zip

SCSA를 준비하기 위한 EBook

출처 : Sun Microsystems

Name

svc.startd– Service Management Facility master restarter

Synopsis

/lib/svc/bin/svc.startd 

svc:/system/svc/restarter:default 

Description

svc.startd is the master restarter daemon for Service Management Facility (SMF) and the default restarter for all services. svc.startd starts, stops, and restarts services based on administrative requests, system failures, or application failures.

svc.startd maintains service state, as well as being responsible for managing faults in accordance with the dependencies of each service.

svc.startd is invoked automatically during system startup. It is restarted if any failures occur. svc.startd should never be invoked directly.

See smf_restarter(5) for information on configuration and behavior common to all restarters.

svcs(1) reports status for all services managed by the Service Configuration Facility. svcadm(1M) allows manipulation of service instances with respect to the service's restarter.

Environment Variables

Environment variables with the “SMF_” prefix are reserved and may be overwritten.

svc.startd supplies the “SMF_” environment variables specified in smf_method(5) to the method. PATH is set to “/usr/sbin:/usr/bin” by default. By default, all other environment variables supplied to svc.startd are those inherited from init(1M).

Duplicate entries are reduced to a single entry. The value used is undefined. Environment entries that are not prefixed with “<name>=” are ignored.

Restarter Options

svc.startd is not configured by command line options. Instead, configuration is read from the service configuration repository. You can use svccfg(1M) to set all options and properties.

The following configuration variables in the options property group are available to developers and administrators:

boot_messages

An astring (as defined in scf_value_is_type; see scf_value_create(3SCF)) that describes the default level of messages to print to the console during boot. The supported message options include quiet and verbose. The quiet option prints minimal messages to console during boot. The verbose option prints a single message per service started to indicate success or failure. You can use the boot -m option to override the boot_messages setting at boot time. See kernel(1M).

logging

Control the level of global service logging for svc.startd. An astring (as defined in scf_value_is_type; see scf_value_create(3SCF)) that describes the default level of messages to log to syslog (see syslog(3C) and svc.startd's global logfile, /var/svc/log/svc.startd.log. The supported message options include quiet, verbose, and debug. The quiet option sends error messages requiring administrative intervention to the console, syslog and svc.startd's global logfile. The verbose option sends error messages requiring administrative intervention to the console, syslog and svc.startd's global logfile, and information about errors which do not require administrative intervention to svc.startd's global logfile. A single message per service started is also sent to the console. The debug option sends svc.startd debug messages to svc.startd's global logfile, error messages requiring administrative intervention to the console, syslog and svc.startd's global logfile, and a single message per service started to the console.

milestone

An FMRI which determines the milestone used as the default boot level. Acceptable options include only the major milestones:

svc:/milestone/single-user:default svc:/milestone/multi-user:default svc:/milestone/multi-user-server:default

or the special values all or none. all represents an idealized milestone that depends on every service. none is a special milestone where no services are running apart from the master svc:/system/svc/restarter:default. By default, svc.startd uses all, a synthetic milestone that depends on every service. If this property is specified, it overrides any initdefault setting in inittab(4).

system/reconfigure

Indicates that a reconfiguration reboot has been requested. Services with actions that must key off of a reconfiguration reboot may check that this property exists and is set to 1 to confirm a reconfiguration boot has been requested.

This property is managed by svc.startd and should not be modified by the administrator.

Configuration errors, such as disabling svc.startd are logged by syslog, but ignored.

SERVICE STATES

Services managed by svc.startd can appear in any of the states described in smf(5). The state definitions are unmodified by this restarter.

SERVICE REPORTING

In addition to any logging done by the managed service, svc.startd provides a common set of service reporting and logging mechanisms.

Reporting properties svc.startd updates a common set of properties on all services it manages. These properties are a common interface that can be used to take action based on service instance health. The svcs(1) command can be used to easily display these properties.

restarter/state
restarter/next_state

The current and next (if currently in transition) state for an instance.

restarter/auxiliary_state

A caption detailing additional information about the current instance state. The auxiliary state available for services managed by svc.startd is:

maintenance

fault_threshold_reached stop_method_failed administrative_request

restarter/state_timestamp

The time when the current state was reached.

restarter/contract

The primary process contract ID, if any, that under which the service instance is executing.

Logs

By default, svc.startd provides logging of significant restarter actions for the service as well as method standard output and standard error file descriptors to /var/svc/log/service:instance.log. The level of logging to system global locations like /var/svc/log/svc.startd.log and syslog is controlled by the options/logging property.

SERVICE DEFINITION

When developing or configuring a service managed by svc.startd, a common set of properties are used to affect the interaction between the service instance and the restarter.

Methods

The general form of methods for the fork/exec model provided by svc.startd are presented in smf_method(5). The following methods are supported as required or optional by services managed by svc.startd.

refresh

Reload any appropriate configuration parameters from the repository or config file, without interrupting service. This is often implemented using SIGHUP for system daemons. If the service is unable to recognize configuration changes without a restart, no refresh method is provided.

This method is optional.

start

Start the service. Return success only after the application is available to consumers. Fail if a conflicting instance is already running, or if the service is unable to start.

This method is required.

stop

Stop the service. In some cases, the stop method can be invoked when some or all of the service has already been stopped. Only return an error if the service is not entirely stopped on method return.

This method is required.

If the service does not need to take any action in a required method, it must specify the :true token for that method.

svc.startd honors any method context specified for the service or any specific method. The method expansion tokens described in smf_method(5) are available for use in all methods invoked by svc.startd.

Properties

An overview of the general properties is available in smf(5). The specific way in which these general properties interacts with svc.startd follows:

general/enabled

If enabled is set to true, the restarter attempts to start the service once all its dependencies are satisfied. If set to false, the service remains in the disabled state, not running.

general/restarter

If this FMRI property is empty or set to svc:/system/svc/restarter:default, the service is managed by svc.startd. Otherwise, the restarter specified is responsible (once it is available) for managing the service.

general/single_instance

If single_instance is set to true, svc.startd only allows one instance of this service to transition to online or degraded at any time.

Additionally, svc.startd managed services can define the optional properties listed below in the startd property group.

startd/duration

The duration property defines the service's model. It can be set to transient, child also known as “wait” model services, or contract (the default).

startd/ignore_error

The ignore_error property, if set, specifies a comma-separated list of ignored events. Legitimate string values in that list are core and signal. The default is to restart on all errors.

startd/need_session

The need_session property, if set to true, indicates that the instance should be launched in its own session. The default is not to do so.

startd/utmpx_prefix

The utmpx_prefix string property defines that the instance requires a valid utmpx entry prior to start method execution. The default is not to create a utmpx entry.

SERVICE FAILURE

svc.startd assumes that a method has failed if it returns a non-zero exit code or if fails to complete before the timeout specified expires. If $SMF_EXIT_ERR_CONFIG or $SMF_EXIT_ERR_FATAL is returned, svc.startd immediately places the service in the maintenance state. For all other failures, svc.startd places the service in the offline state. If a service is offline and its dependencies are satisfied, svc.startd tries again to start the service (see smf(5)).

If a contract or transient service does not return from its start method before its defined timeout elapses, svc.startd sends a SIGKILL to the method, and returns the service to the offline state.

If three failures happen in a row, or if the service is restarting more than once a second, svc.startd places the service in the maintenance state.

The conditions of service failure are defined by a combination of the service model (defined by the startd/duration property) and the value of the startd/ignore_error property.

A contract model service fails if any of the following conditions occur:

• all processes in the service exit

• any processes in the service produce a core dump

• a process outside the service sends a service process a fatal signal (for example, an administrator terminates a service process with the pkill command)

The last two conditions may be ignored by the service by specifying core and/or signal in startd/ignore_error.

Defining a service as transient means that svc.startd does not track processes for that service. Thus, the potential faults described for contract model services are not considered failures for transient services. A transient service only enters the maintenance state if one of the method failure conditions occurs.

“Wait” model services are restarted whenever the child process associated with the service exits. A child process that exits is not considered an error for “wait” model services, and repeated failures do not lead to a transition to maintenance state.

LEGACY SERVICES

svc.startd continues to provide support for services invoked during the startup run level transitions. Each /etc/rc?.d directory is processed after all managed services which constitute the equivalent run level milestone have transitioned to the online state. Standard init scripts placed in the /etc/rc?.d directories are run in the order of their sequence numbers.

The milestone to run-level mapping is:

milestone/single-user

Single-user (S)

milestone/multi-user

Multi-user (2)

milestone/multi-user-server

Multi-user with network services (3)

Additionally, svc.startd gives these legacy services visibility in SMF by inserting an instance per script into the repository. These legacy instances are visible using standard SMF interfaces such as svcs(1), always appear in the LEGACY-RUN state, cannot be modified, and can not be specified as dependencies of other services. The initial start time of the legacy service is captured as a convenience for the administrator.

Files

/var/svc/log

Directory where svc.startd stores log files.

/etc/svc/volatile

Directory where svc.startd stores log files in early stages of boot, before /var is mounted read-write.

EXAMPLE

---

Example 1 Turning on Verbose Logging




To turn on verbose logging, type the following:

# /usr/sbin/svccfg -s system/svc/restarter:default svc:/system/svc/restarter:default> addpg options application svc:/system/svc/restarter:default> setprop options/logging = \ astring: verbose svc:/system/svc/restarter:default> exit

This request will take effect on the next restart of svc.startd.

---

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

See Also

svcs(1), svcprop(1), kernel(1M), init(1M), svcadm(1M), svccfg(1M), svc.configd(1M), setsid(2), syslog(3C), libscf(3LIB), scf_value_create(3SCF), contract(4), init.d(4), process(4), inittab(4), attributes(5), smf(5), smf_method(5)

Name

setfacl– modify the Access Control List (ACL) for a file or files

Synopsis

setfacl [-r] -s acl_entries file

setfacl [-r] -md acl_entries file

setfacl [-r] -f acl_file file

Description

For each file specified, setfacl either replaces its entire ACL, including the default ACL on a directory, or it adds, modifies, or deletes one or more ACL entries, including default entries on directories.

When the setfacl command is used, it can result in changes to the file permission bits. When the user ACL entry for the file owner is changed, the file owner class permission bits are modified. When the group ACL entry for the file group class is changed, the file group class permission bits are modified. When the other ACL entry is changed, the file other class permission bits are modified.

If you use the chmod(1) command to change the file group owner permissions on a file with ACL entries, both the file group owner permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the effective permissions for additional users and groups who have ACL entries on the file.

A directory can contain default ACL entries. If a file or directory is created in a directory that contains default ACL entries, the newly created file has permissions generated according to the intersection of the default ACL entries and the permissions requested at creation time. The umask(1) are not applied if the directory contains default ACL entries. If a default ACL is specified for a specific user (or users), the file has a regular ACL created. Otherwise, only the mode bits are initialized according to the intersection described above. The default ACL should be thought of as the maximum discretionary access permissions that can be granted.

Use the setfacl command to set ACLs on files in a UFS file system, which supports POSIX-draft ACLS (or aclent_t style ACLs). Use the chmod command to set ACLs on files in a ZFS file system, which supports NFSv4-style ACLS (or ace_t style ACLs).

acl_entries Syntax

For the -m and -s options, acl_entries are one or more comma-separated ACL entries.

An ACL entry consists of the following fields separated by colons:

entry_type

Type of ACL entry on which to set file permissions. For example, entry_type can be user (the owner of a file) or mask (the ACL mask).

uid or gid

User name or user identification number. Or, group name or group identification number.

perms

Represents the permissions that are set on entry_type. perms can be indicated by the symbolic characters rwx or a number (the same permissions numbers used with the chmod command).

The following table shows the valid ACL entries (default entries can only be specified for directories):

ACL Entry	Description
u[ser]::perms	File owner permissions.
g[roup]::perms	File group owner permissions.
o[ther]:perms	Permissions for users other than the file owner or members of file group owner.
m[ask]:perms	The ACL mask. The mask entry indicates the maximum permissions allowed for users (other than the owner) and for groups. The mask is a quick way to change permissions on all the users and groups.
u[ser]:uid:perms	Permissions for a specific user. For uid, you can specify either a user name or a numeric UID.
g[roup]:gid:perms	Permissions for a specific group. For gid, you can specify either a group name or a numeric GID.
d[efault]:u[ser]::perms	Default file owner permissions.
d[efault]:g[roup]::perms	Default file group owner permissions.
d[efault]:o[ther]:perms	Default permissions for users other than the file owner or members of the file group owner.
d[efault]:m[ask]:perms	Default ACL mask.
d[efault]:u[ser]:uid:perms	Default permissions for a specific user. For uid, you can specify either a user name or a numeric UID.
d[efault]:g[roup]:gid:perms	Default permissions for a specific group. For gid, you can specify either a group name or a numeric GID.

For the -d option, acl_entries are one or more comma-separated ACL entries without permissions. Notice that the entries for file owner, file group owner, ACL mask, and others can not be deleted.

Options

The options have the following meaning:

-d acl_entries

Deletes one or more entries from the file. The entries for the file owner, the file group owner, and others can not be deleted from the ACL. Notice that deleting an entry does not necessarily have the same effect as removing all permissions from the entry.

-f acl_file

Sets a file's ACL with the ACL entries contained in the file named acl_file. The same constraints on specified entries hold as with the -s option. The entries are not required to be in any specific order in the file. Also, if you specify a dash (-) for acl_file, standard input is used to set the file's ACL.

The character # in acl_file can be used to indicate a comment. All characters, starting with the # until the end of the line, are ignored. Notice that if the acl_file has been created as the output of the getfacl(1) command, any effective permissions, which follow a #, are ignored.

-m acl_entries

Adds one or more new ACL entries to the file, and/or modifies one or more existing ACL entries on the file. If an entry already exists for a specified uid or gid, the specified permissions replace the current permissions. If an entry does not exist for the specified uid or gid, an entry is created. When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time.

-r

Recalculates the permissions for the ACL mask entry. The permissions specified in the ACL mask entry are ignored and replaced by the maximum permissions necessary to grant the access to all additional user, file group owner, and additional group entries in the ACL. The permissions in the additional user, file group owner, and additional group entries are left unchanged.

-s acl_entries

Sets a file's ACL. All old ACL entries are removed and replaced with the newly specified ACL. The entries need not be in any specific order. They are sorted by the command before being applied to the file.

Required entries:

• Exactly one user entry specified for the file owner.

• Exactly one group entry for the file group owner.

• Exactly one other entry specified.

If there are additional user and group entries:

• Exactly one mask entry specified for the ACL mask that indicates the maximum permissions allowed for users (other than the owner) and groups.

• Must not be duplicate user entries with the same uid.

• Must not be duplicate group entries with the same gid.

If file is a directory, the following default ACL entries can be specified:

• Exactly one default user entry for the file owner.

• Exactly one default group entry for the file group owner.

• Exactly one default mask entry for the ACL mask.

• Exactly one default other entry.

There can be additional default user entries and additional default group entries specified, but there can not be duplicate additional default user entries with the same uid, or duplicate default group entries with the same gid.

Examples

---

Example 1 Adding read permission only




The following example adds one ACL entry to file abc, which gives user shea read permission only.

setfacl -m user:shea:r-- abc

---

---

Example 2 Replacing a file's entire ACL




The following example replaces the entire ACL for the file abc, which gives shea read access, the file owner all access, the file group owner read access only, the ACL mask read access only, and others no access.

setfacl -s user:shea:rwx,user::rwx,group::rw-,mask:r--,other:--- abc

Notice that after this command, the file permission bits are rwxr-----. Even though the file group owner was set with read/write permissions, the ACL mask entry limits it to have only read permission. The mask entry also specifies the maximum permissions available to all additional user and group ACL entries. Once again, even though the user shea was set with all access, the mask limits it to have only read permission. The ACL mask entry is a quick way to limit or open access to all the user and group entries in an ACL. For example, by changing the mask entry to read/write, both the file group owner and user shea would be given read/write access.

---

---

Example 3 Setting the same ACL on two files




The following example sets the same ACL on file abc as the file xyz.

getfacl xyz | setfacl -f - abc

---

Files

/etc/passwd

password file

/etc/group

group file

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

See Also

chmod(1), getfacl(1), umask(1), aclcheck(3SEC), aclsort(3SEC), group(4), passwd(4), attributes(5)