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.
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
inactiveYour 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.
Checkpoint: if command -v acpid fails, install the distribution package through your normal package-management process before continuing. If the daemon is inactive, no rule will run until a service manager starts it.
By default, acpid reads regular files in /etc/acpi/events. Naming rules decide what gets loaded:
$ sudo find /etc/acpi/events -maxdepth 1 -type f -printf '%f\n' | sort
$ sudo sed -n '1,120p' /etc/acpi/events/EXISTING_RULEReplace 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.
Warning: this changes system configuration. Take a backup of the exact file you are about to create and keep the original event rules available for rollback before running the privileged command below.
$ 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-logThe .* 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.
Warning: do not use this as a shutdown rule. A power-button action that powers off a machine is service-disrupting and needs its own design with an explicit recovery plan, not a quick edit here.
Checkpoint: inspect the file exactly as the daemon will see it:
$ 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"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-pagerThe 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.
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 00000000The 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.
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.logThe 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.
/etc/acpi/events does nothing until a running daemon reloads its rules or restarts.power-button-log~, are skipped.%e can contain spaces; quote it when the whole event must be one argument.--nosocket disables the UNIX event socket and overrides --socketfile; do not add it while a client needs notifications./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.