man Pages(4): File Formats

power.conf(4)

NAME

power.conf- power management configuration information file

SYNOPSIS

/etc/power.conf

DESCRIPTION

The power.conf file is used by the power management configuration program, pmconfig(1M), to initialize the settings for power management of the system.

There are two types of entries in the power.conf file: device management entries and system management entries.

Device Management

Devices not appearing in this file will not be power managed without explicit configuration using the power management pseudo driver. See pm(7D). You should fully understand the power management framework before modifying device management entries in this file. Although inappropriate settings will not cause system damage, severe performance reduction may result. An entry in power.conf will be effective only if the driver for the device supports device power management.

Device management entries consist of line by line listings of the devices to be configured. Each line is of the form:

device_name     threshold ...	   dependents ...

The fields must be in this order. Each line must contain a device_name field and a threshold field; it may also contain a dependents field. Fields and sub-fields are separated by white space (tabs or spaces). A line may be more than 80 characters. If a newline character is preceded by a backslash ('\') it will be treated as white space. Comment lines must begin with a hash character ('#').

The device_name field specifies the device to be configured. device_name is either a pathname specifying the device special file or a relative pathname containing the name of the device special file. When using the latter format, instead of using the full pathname, it is possible to omit the portion of the pathname specifying the parent devices. This includes the leading '/'. Using this "relative" pathname format, the first device found with a full pathname containing device_name as its tail is matched. In either case, the leading /devices component of the pathname does not need to be specified.

For example, a SCSI disk target with the following full path name:

/iommu@f,e000/sbus@f,e001/espdma@f,4000/esp@f,8000/sd@1,0

may also be specified as:

sbus@f,e000/espdma@f,4000/esp@f,8000/sd@1,0

esp@f,8000/sd@1,0

sd@1,0

The threshold field is used to configure the power manageable components of a device. These components represent entities within a device that may be power-managed separately. This field may contain as many integer values as the device has components. Each threshold time specifies the idle time in seconds before the respective component may be powered down. If there are fewer component threshold times than device components, the remaining components are not power managed. Use a value of -1 to explicitly disable power-down for a component. At least one component threshold must be specified per device (in the file).

The dependents field may contain a list of logical dependents for this device. A logical dependent is a selected device that is not physically connected to the power managed device (for example, the display and the keyboard). A dependent device is one that must be idle and powered-down before the managed device can be powered down. The dependents field entries use the same format as the first field and are separated by white spaces. A device must previously have been configured before it can be used as a dependent.

Device power management entries for frame buffers are only effective when the X window system is not running. If either the Open Window or Common Desktop Environment window system is running, it takes over power management of the display devices that it is using.

System Management

The system management entries control power management for the entire system. They are distinguished by the use of the special device names listed below.

Note that the following autoshutdown entry is not intended to be hand edited, but to be maintained by the dtpower utility.

If the device_name field contains the special device name autoshutdown, the threshold value specifies the system idle time (measured as discussed below) before the system may be shut down by powerd(1M). The threshold value is followed by start and finish times (each in the format hh:mm) which specify the time period during which the system may be automatically shut down (see powerd(1M)). Following the start and finish times is the behavior field, which can be shutdown, noshutdown, autowakeup, default, or unconfigured.

Acceptable behavior values and their meanings are:

shutdown: The system will be shut down automatically when it has been idle for the number of minutes specified in the threshold value and the time of day falls between the start and finish values.
noshutdown: The system is never shut down automatically.
autowakeup: If the hardware has the capability to do autowakeup, the system is shut down as if the value were shutdown and the system will be restarted automatically the next time the time of day equals the finish time.
default: The behavior of the system will depend upon its model. Desktop models that were first put into production after October 1, 1995 will behave as if the behavior field were set to shutdown. Desktop models first put into production before this date and server models will act as if the behavior field were set to noshutdown. The behavior is determine by a root node property named energystar-v2.
unconfigured: The system will not be shut down automatically. If the system has just been installed or upgraded, the value of this field will be changed upon the next reboot. If the power management package has been added by hand, the dtpower utility must be run to set the correct autoshutdown behavior.

If the device_name field contains the special device name statefile, the threshold value specifies the location of the file used by cpr(7). The cpr module uses this file to record the state of the system prior to powering it down.

This entry has the following format:

statefile pathname

where pathname identifies a block special file, for example /dev/dsk/c1t0d0s3, or is the absolute pathname of a local ufs file.

If pathname specifies a local ufs file, it cannot be a symbolic link. If the file does not exist when it is time for a checkpoint to be taken, cpr will create it. All the directory components of the path must already exist.

If pathname specifies a block special file, then it may be a symbolic link, as long as it does not have a file system mounted on it.

The actual size required by cpr to checkpoint the system state at any given time depends on a variety of factors, including the size of the system's memory, the number of loadable drivers/modules in use, the number and type of processes running, and the amount of user memory that has been "locked down".

If cpr fails to complete a checkpoint due to insufficient space on the file system or block special file specified for the statefile, an explanatory message will be displayed on the console and written to the system log, and the system will be returned to its state prior to the checkpoint attempt.

It is recommended that the statefile be placed on a file system with at least 10 Mbytes of free space. In order that a newly installed system will have a statefile path which meets this requirement, a script run at boot time checks for the existence of the power.conf file. If the file exists but lacks a statefile entry, the script will create one using a simple method to determine the pathname. It first examines the free space in the root file system, and if there is sufficient space, an appropriate entry is added to power.conf. It then applies the same test to /usr, if it is a separate file system. If this also fails, it checks the file system of those remaining (if any) that has the largest number of free blocks. If all three of these checks fail, a message is be displayed warning the user of the failure. If the pathname entry is created by the system, the final component of the name will be .CPR.

To further reduce the possibility of a checkpoint failure, the file system should have free space equivalent to at least one half of the system's memory (RAM). To modify the statefile location, edit the statefile entry in power.conf, replacing the existing path with the new one. After saving the file and exiting the editor, run the pmconfig(1M) command with no arguments.

Some types of application, such as proprietary data base packages, achieve higher performance by using Solaris system calls that lock a large number of user pages into memory. In such cases, the amount of space required for the cpr statefile should be increased by the total space of such locked down memory.

The device_name field also recognizes the following names:

ttychars

If the device_name is ttychars, the threshold field will be interpreted as the maximum number of tty characters that can pass through the ldterm module while still allowing the system to be considered idle. This value defaults to 0 if no entry is provided.

loadaverage

If the device_name is loadaverage, the (floating point) threshold field will be interpreted as the maximum load average that can be seen while still allowing the system to be considered idle. This value defaults to 0.04 if no entry is provided.

diskreads

If the device_name is diskreads, the threshold field will be interpreted as the maximum number of disk reads that can be perform by the system while still allowing the system to be considered idle. This value defaults to 0 if no entry is provided.

nfsreqs

If the device_name is nfsreqs, the threshold field will be interpreted as the maximum number of NFS requests that can be sent or received by the system while still allowing the system to be considered idle. Null requests, access requests, and gettattr requests are excluded from this count. This value defaults to 0 if no entry is provided.

idlecheck

If the device_name is idlecheck, the device_name field must be followed by the pathname of a program to be executed to determine if the system is idle. If autoshutdown is enabled and the console keyboard, mouse, tty, CPU (as indicated by load average), network (as measured by NFS requests) and disk (as measured by read activity) have been idle for the amount of time specified in the autoshutdown entry specified above, and the time of day falls between the start and finish times, then this program will be executed to check for other idleness criteria. The value of the idle time specified in the above autoshutdown entry will be passed to the program in the environment variable PM_IDLETIME. The process must terminate with an exit code that represents the number of minutes that the process considers the system to have been idle.

There is no default idlecheck entry. The default behavior is to consider only mouse, keyboard, tty, load average, NFS requests, and disk reads as indicators of non-idleness. To extend the definition of non-idleness, a shell script can be created that must exit with the number of minutes it considers the system to have been idle, according to its criteria. The path to this new script can then be stored in the idlecheck entry in power.conf.

EXAMPLES

power.conf file

The following is a sample power.conf file.

# This is a sample power management configuration file
# Fields must be separated by white space.
#
# Name     	    Threshold(s)    Logical Dependent(s)
/dev/kbd  	    1800
/dev/mouse	    1800
/dev/fb    	    0 0		    /dev/kbd /dev/mouse
#Example of a second display
/dev/fb1    	    0 0		    /dev/kbd /dev/mouse
# This entry is maintained by the dtpower utility
# This (default as of SunOS 5.5) entry causes the system to be
# shut down after 30 minutes of idle time if it is a model first
# shipped after Oct 1, 1995.  Older models default to noshutdown.
#
# 					autoshutdown in effect
# Auto-Shutdown      	Idle(min) 	Start/Finish(hh:mm)	Behavior
autoshutdown        	30        	9:00 9:00 	 	default
# Statefile		Path
statefile		/export/home/.CPR
# The idlecheck program is passed the autoshutdown idle time entry in
# the environment variable $PM_IDLETIME and it must return the number of
# minutes the system has been idle (by its criteria) in its exit code.
idlecheck    /home/critical/idlecheck

idlecheck script

The following is a sample idlecheck script.

#!/bin/sh
# This is a sample idlecheck script which considers the system
# not idle if user "critical" is logged in
critical=`who|grep -w critical`
if [ "$critical" ]		# if "$critical" is not null string
then
	exit 0			# not idle because critical logged in
else
	exit $PM_IDLETIME	# idle long enough
fi

ATTRIBUTES

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

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWpmr

NOTES

The default behavior for desktop models introduced after October 1, 1995 is to shut down after 30 minutes of idleness any time of day. The dtpower utility can be used to change the default.

The default behavior is mandated by the U.S. Government Environmental Protection Agency as a requirement for EnergyStar compliance. The user will be prompted to confirm this default at system installation reboot, or during the first boot after the system is unconfigured by sys-unconfig(1M).

The user may wish to use the dtpower utility to set the autoshutdown start time to the end of the normal work day, and to set the autoshutdown finish time to the start of the normal work day.

The physical dependents are automatically included by the power manager and need not be specified.

The default power.conf file supports the standard hardware configuration. For each additional power manageable device (such as a second display), a new entry must be manually added to the power.conf file and pmconfig(1M) must be executed to activate the new change.

Frequently powering devices up and down may reduce device reliability, especially for devices not designed for power management. Do not place additional devices under power management unless the hardware documentation permits it. At this time most, SCSI hard disks are not power-manageable.

SunOS 5.7 Last Revised 29 Jul 1998