Watch ACPI Events Safely with acpi_listen

acpi_listen sits on the ACPI daemon's socket and prints every lid, button and power event as it happens. You will finish with a controlled way to watch those events, plus checks for the socket and command version.

The examples use acpi_listen from Ubuntu's acpid package version 1:2.0.34-1ubuntu2, which reports itself as acpid-2.0.34. Allow about ten minutes. You need a shell and an ACPI daemon that is running and accepting connections. Watching is normally an ordinary-user operation. Starting or restarting the daemon changes system service state and is not part of the basic workflow, so keep that separate.

1. Check the installed command

Confirm the binary and its supported options before copying an example. These commands only read local information:

$ command -v acpi_listen
/usr/bin/acpi_listen
$ acpi_listen --version
acpid-2.0.34
$ acpi_listen --help
Usage: acpi_listen [OPTIONS]
  -c, --count       Set the maximum number of events.
  -s, --socketfile  Use the specified socket file.
  -t, --time        Listen for the specified time (in seconds).
  -v, --version     Print version information.
  -h, --help        Print this message.

2. Check the daemon socket

acpi_listen connects to the UNIX socket opened by acpid. The documented default is /var/run/acpid.socket:

$ stat /var/run/acpid.socket
  File: /var/run/acpid.socket
  File type: socket

The exact stat fields vary by operating system. The useful result is that the path exists and is a socket, not a regular file or a missing path. You can also ask systemd for the service state without changing it:

$ systemctl is-active acpid
active

If your host uses another init system, or the socket has been configured elsewhere, do not assume that active is the right command. Use the socket path supplied by the daemon's configuration and pass it with --socketfile.

3. Watch events until you stop

Run the listener with no options:

$ acpi_listen

It waits for ACPI events and writes each received event to standard output. The manpage deliberately describes the output only as the event itself, so do not build a parser around an undocumented sample line. Generate a harmless event appropriate to the machine, such as opening and closing a laptop lid only when doing so is safe, or press a spare hardware key if one is available.

Stop the foreground listener with Ctrl-C. That ends this client process and does not stop acpid or alter its configuration.

4. Bound the number of events

For a script or a repeatable manual test, use --count:

$ acpi_listen --count 1
# trigger one safe ACPI event, then the command exits

The option sets a maximum number of events. It does not create an event and it does not guarantee that the command will exit promptly if no event arrives. If the terminal is still waiting, press Ctrl-C. There is no persistent state to undo.

Use a non-zero count when you need more than one event. Keep the listener in the foreground while testing so that its output and exit point are visible rather than disappearing into a service or background job.

5. Select a different socket

If the daemon was configured with a non-default socket, pass that path explicitly:

$ SOCKET_PATH='/run/acpid-custom.socket'
$ stat "$SOCKET_PATH"
$ acpi_listen --socketfile "$SOCKET_PATH"

Replace /run/acpid-custom.socket with the real path. Do not create a socket file yourself. A missing path, an ordinary file, or a socket belonging to an incompatible daemon will not provide ACPI events. If access is denied, ask an administrator to review the socket's ownership and permissions rather than making them broadly writable.

6. Treat timed listening carefully on this build

The manpage documents --time as a way to listen for a number of seconds:

$ acpi_listen --time 10

Do not use --time as a health check on this installation. Prefer --count with a safe event, or run the unbounded listener and stop it with Ctrl-C. If you must investigate the crash, capture the package version, socket state and service logs for the distribution maintainer. Do not repeatedly run a crashing command in a production monitoring loop.

7. Separate client failures from service failures

When no events appear, check one layer at a time:

1. Run acpi_listen --version to confirm the command is present.
2. Run stat /var/run/acpid.socket to check the default endpoint.
3. Run systemctl is-active acpid if the host uses systemd.
4. Run acpi_listen --help to confirm the option syntax.

A missing socket normally points to the daemon or its configuration, while a permission error points to access control. A listener that is simply waiting has not failed: it has not received an event. Avoid changing service files, socket permissions or boot settings until those distinctions are clear. Any such change can affect other users and services and should be planned as an administrator action with a rollback.