How Linux Manages the acpid Daemon

The acpid (Advanced Configuration and Power Interface event daemon) service in Linux acts as a bridge between low-level hardware events and user-space actions, enabling the operating system to react dynamically to physical triggers such as pressing the power button, closing a laptop lid, or unplugging an AC adapter. By listening to kernel-generated event streams, acpid decodes ACPI signals and executes predefined shell scripts or system commands according to user configuration. This article explains how the Linux kernel detects ACPI hardware events, how the acpid daemon listens for and routes these signals, and how modern distributions configure and manage this service alongside systemd.

Kernel Event Detection and Forwarding

When a user interacts with ACPI-compliant hardware—such as pressing a sleep key or docking a laptop—the hardware triggers an interrupt. The Linux kernel's ACPI subsystem catches this interrupt via firmware-defined tables.

Once detected, the kernel packages the occurrence into an event string and exposes it to user space. Historically, this was routed through /proc/acpi/event. In modern Linux kernels, events are typically broadcast through standard input devices (/dev/input/event*) or through the kernel's netlink interface via the genetlink module. This design eliminates polling, allowing user-space applications to respond asynchronously and immediately.

The Lifecycle and Operation of acpid

The acpid daemon runs as a continuous background process with root privileges, necessary for performing system-level operations like halting the system or changing hardware brightness levels.

  1. Initialization: During system boot, the init system (such as systemd via acpid.service) starts the daemon. Upon launch, acpid opens communication channels with the kernel—primarily listening on /dev/input/event* devices and the netlink ACPI family.
  2. Monitoring: The daemon waits for incoming messages using event loops (epoll or select). This prevents unnecessary CPU usage while waiting for hardware triggers.
  3. Parsing: When an ACPI event fires, the kernel sends a descriptive string or input event code (for example, button/power PBTN 00000080 00000000). The daemon reads and parses this string into event categories, types, and values.

Rule Matching and Event Handling

After parsing an event, acpid determines how to respond by evaluating configuration files located in /etc/acpi/events/.

Each configuration file in this directory typically contains two key directives:

For example, a configuration file for a power button might look like:

event=button/power.*
action=/etc/acpi/powerbtn.sh "%e"

The %e token passes the raw event string directly into the designated action script. The script located in /etc/acpi/powerbtn.sh then executes the required logic, such as calling systemctl poweroff or alerting desktop environments to open a shutdown confirmation dialog.

If multiple configuration files match a single incoming event, acpid executes each action sequentially in alphanumeric order based on the configuration file names.

Coexistence with systemd-logind

In modern Linux distributions running systemd, systemd-logind natively handles several common ACPI power events by default, including:

When both systemd-logind and acpid are active simultaneously, a conflict can occur where an event triggers twice (for instance, the system suspending twice upon lid closure).

To manage this, administrators choose between two configurations: