Log an ACPI Event with acpid Without a Reboot

Your laptop's power button does something you did not ask for, and acpid is the obvious suspect, except the daemon might not even be the one running. This walks through checking its real state, adding a harmless logging rule, reloading it live, and rolling the whole thing back. Allow 15 to 20 minutes. You need root for the configuration and service steps, plus a normal shell account for inspection.

This guide matches the installed acpid package, version 1:2.0.34-1ubuntu2; the executable reports acpid-2.0.34. On this machine the service is installed but disabled and inactive, which is the trap: a package being present tells you nothing about who is actually handling events.

1. Check the daemon and its current state

Start with reads only, nothing here touches configuration:

$ command -v acpid
/usr/sbin/acpid
$ acpid --version
acpid-2.0.34
$ systemctl is-enabled acpid
disabled
$ systemctl is-active acpid
inactive

Your service state may differ, and that is the point. Do not assume that installing the package means acpid is the component currently processing the power button or lid switch.

2. Find the rule directory and read its naming rules

By default, acpid reads regular files in /etc/acpi/events. Naming rules decide what gets loaded:

• Allowed characters only. Names made from letters, digits, underscores and hyphens are loaded.
• Dotfiles are skipped. A name beginning with a dot is ignored.
• Backup files are skipped. A name ending in a tilde is ignored, which quietly protects you from editor backup files.

$ sudo find /etc/acpi/events -maxdepth 1 -type f -printf '%f\n' | sort
$ sudo sed -n '1,120p' /etc/acpi/events/EXISTING_RULE

Replace EXISTING_RULE with a filename the first command actually printed; the second command is deliberately not paste-ready until you do. Read existing rules before adding another one, because several rules can match one event and their execution order is not guaranteed.

Each rule needs an event line and an action line. The event is a regular expression. The action runs through /bin/sh, so shell metacharacters are meaningful and deserve the same care as any other shell script.

3. Add a harmless event logger

$ sudo install -d -m 0755 /etc/acpi/events
$ sudo sh -c 'cat > /etc/acpi/events/power-button-log' <<'EOF'
event=button/power.*
action=/bin/sh -c 'printf "acpid power event: %s\n" "$1" >> /var/log/acpid-power-events.log' -- "%e"
EOF
$ sudo chmod 0644 /etc/acpi/events/power-button-log

The .* lets the rest of the event line vary. The action passes %e as one shell argument, preserving spaces in the event: the first argument after -c is the shell's placeholder name, so the event becomes $1. The log file is created by the action itself the first time a matching event arrives.

$ sudo sed -n '1,20p' /etc/acpi/events/power-button-log
event=button/power.*
action=/bin/sh -c 'printf "acpid power event: %s\n" "$1" >> /var/log/acpid-power-events.log' -- "%e"

4. Reload the rules without restarting the daemon

Send SIGHUP to a running daemon so it reparses its configuration. First locate its PID from the documented default pidfile:

$ sudo test -r /var/run/acpid.pid && sudo cat /var/run/acpid.pid
1234
$ sudo kill -HUP "$(sudo cat /var/run/acpid.pid)"
$ sudo journalctl -u acpid --since "2 minutes ago" --no-pager

The number 1234 is an example; use whatever your machine prints. If the pidfile is absent, the daemon may not be running, or it may have started with --pidfile pointing elsewhere. Do not kill a process merely because it has a plausible number: verify the service state first with systemctl status acpid --no-pager.

A reload applies rule changes without a service restart. If a rule contains an unknown percent escape, or otherwise fails to load, the daemon warns and skips that rule. The only documented substitutions are %e for the literal event and %% for a literal percent sign.

5. Trigger and verify the rule safely

Only test with an event you can trigger without risking data loss. For a physical power button, save your work first and check what your system's power policy actually does. Then inspect the log:

$ sudo tail -n 20 /var/log/acpid-power-events.log
acpid power event: button/power PBTN 00000080 00000000

The exact event text depends on the kernel and hardware. If the log does not change, use kacpimon or acpi_listen to confirm whether the kernel is producing the expected event at all, as the acpid(8) troubleshooting notes suggest. If an event shows up there but the action does not run, check the rule filename, the regular expression, shell quoting, daemon logs and the permissions on the log destination, in that order.

Desktop power settings and systemd's logind can also handle power and lid events. A working acpid rule does not prove it is the only handler, and two handlers can produce surprising results together. Check HandlePowerKey and the relevant desktop power settings before adding an action with real side effects.

6. Roll back the test rule

Once the event is verified, remove the temporary rule and reload. This is a deliberate configuration change; keep the command visible so a later reader can undo it too:

$ sudo rm -- /etc/acpi/events/power-button-log
$ sudo kill -HUP "$(sudo cat /var/run/acpid.pid)"
$ sudo rm -- /var/log/acpid-power-events.log

The last command deletes the test log and cannot recover entries from it; omit that line if the log holds evidence you need to keep. If the rule replaced an existing file, restore that file from your backup before sending SIGHUP.

Common traps

• Nothing happens after editing. Changing /etc/acpi/events does nothing until a running daemon reloads its rules or restarts.
• A rule is silently ignored. Filenames that look like editor backups, such as power-button-log~, are skipped.
• Spaces get split. %e can contain spaces; quote it when the whole event must be one argument.
• Clients stop getting events. --nosocket disables the UNIX event socket and overrides --socketfile; do not add it while a client needs notifications.
• A lock file blocks everything. The default socket is /var/run/acpid.socket, the default pidfile is /var/run/acpid.pid, and the default lock file is /var/lock/acpid. A lock file makes the daemon ignore incoming events entirely.