From ArchWiki
Revision as of 01:18, 29 October 2011 by AskApache (talk | contribs) (removed bad link)
Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

acpid is a flexible and extensible daemon for delivering ACPI events. These events are triggered by certain actions, such as:

  • Pressing the Power button
  • Pressing the Sleep/Suspend button
  • Closing a notebook lid
  • (Un)Plugging an AC power adapter from a notebook

acpid can be used by itself, or combined with a more robust system such as Pm-utils and Cpufrequtils to provide a more complete power management solution.


The Template:Package Official package is available in [extra].

Edit Template:Filename as root and add acpid to the DAEMONS array to have it start on boot.


acpid comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in Template:Filename, which is executed after any ACPI events are detected (as determined by Template:Filename).

The following is a brief example of one such action. In this case, when the Sleep Button is pressed, acpid runs the command Template:Codeline which should place the computer into a sleep (suspend) state:

    case "$2" in
        SLPB) echo -n mem >/sys/power/state ;;
	 *)    logger "ACPI action undefined: $2" ;;

Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as SLPB and on another as SBTN.

To determine how your buttons or Fn shortcuts are recognized, run the following command from a terminal as root:

# tail -f /var/log/messages.log

Now press the Power button and/or Sleep button (e.g. Fn+Esc) on your machine. The result should look something this:

logger: ACPI action undefined: PBTN
logger: ACPI action undefined: SBTN

If that does not work, run:

# acpi_listen

Then press the power button and you will see something like this:

power/button PBTN 00000000 00000b31

The output of acpi_listen is sent to as $1, $2 , $3 & $4 parameters. example :

$1 power/button
$3 00000000
$4 00000b31

As you might have noticed, the Sleep button in the sample output is actually recognized as SBTN, rather than the SLPB label specified in the default Template:Filename. In order for Sleep function to work properly on this machine, we would need to replace SLPB) with SBTN).

Using this information as a base, you can easily customize the Template:Filename file to execute a variety of commands depending on which event is triggered. See the Tips & Tricks section below for other commonly used commands.

Alternative configuration

By default, all ACPI events are passed through the Template:Filename script. This is due to the ruleset outlined in Template:Filename:

 # Pass all events to our one handler script
 action=/etc/acpi/ %e

While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:

As root, create and edit the file: Template:Filename. Add the following:

event=button sleep.*
action=/etc/acpi/actions/ "%e"

Now create and edit the file: Template:Filename. Add:

case "$2" in
    SLPB) echo -n mem >/sys/power/state ;;
    *)    logger "ACPI action undefined: $2" ;;

Finally, make the script executable:

# chmod +x /etc/acpi/actions/

Using this method, it is easy to create any number of individual event/action scripts.

Tips & Tricks

Extending acpid with pm-utils

Although Template:Codeline can provide basic suspend2ram out-of-the-box, a more robust system may be desired. Pm-utils provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, Template:Codeline and Template:Codeline, both of which can be inserted as events into acpid. For more information, check the Pm-utils wiki.

Sample Events

The following are samples of events that can be dropped into the existing Template:Filename script. Bolded text indicates modifications or additions to the default script. As noted above, your event labels may differ so some tweaking may be necessary.

Activate Xscreensaver upon lid closure:

    #echo "LID switched!">/dev/tty5
        IS_ACTIVE="$( pidof /usr/bin/xscreensaver )"

        if [ -n "$IS_ACTIVE" ]
            # run the lock command as the user who owns xscreensaver process,
            # and not as root, which won't work (see: man xscreensaver-command)
            su "$( ps aux | grep xscreensaver | grep -v grep | grep $IS_ACTIVE | awk '{print $1}' )" -c "/usr/bin/xscreensaver-command -lock" &

Suspend the system and lock the screen using slimlock when the lid is closed:

        #echo "LID switched!">/dev/tty5
	DISPLAY=:0.0 su -c - username /usr/bin/slimlock

Execute Template:Codeline (from Pm-utils) when the Sleep button is pressed:

    case "$2" in
	     #echo -n mem >/sys/power/state

Laptop Monitor Power Off

Adapted from the Gentoo Wiki comes this little gem. Add this to the bottom of Template:Filename or to the button/lid section Template:Filename. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.

case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in
    closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;
    open)   XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on  ;;

If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.

With certain combinations of Xorg and stubborn hardware, xset dpms force off only blanks the display leaving the backlight turned on. This can be fixed using vbetool from the 'extra' repository. Change the LCD section to:

case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in
    closed) vbetool dpms off ;;
    open)   vbetool dpms on  ;;

If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual dpms settings.

Getting user name of the current display

You can use the function Template:Codeline to acquire the user of the current display:

getuser ()
     export DISPLAY=`echo $DISPLAY | cut -c -2`
     user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`
     export XAUTHORITY=/home/$user/.Xauthority
     eval $1=$user

This function can be used for example, when you press the power button and want to shutdown KDE properly:

    case "$2" in
            getuser "$user"
            echo $user > /dev/tty5
            su $user -c "dcop ksmserver ksmserver logout 0 2 0"
          *) logger "ACPI action undefined $2" ;;

More Resources