Having acpid.path monitor /etc/acpi/events with inotify to then trigger acpid.service that is not runnable inside a container causes an endless loop that causes a log flood:
# journalctl -fu acpid.service
...
systemd[1]: Condition check resulted in ACPI event daemon being skipped.A similar issue occurs when acpid.socket receives a connection inside a container. This can be simulated with nc -U /run/acpid.socket which causes the following failure:
# systemctl status acpid.socket
× acpid.socket - ACPID Listen Socket
Loaded: loaded (/lib/systemd/system/acpid.socket; enabled; vendor preset: enabled)
Active: failed (Result: trigger-limit-hit) since Wed 2022-06-08 00:05:20 UTC; 27s ago
Triggers: ● acpid.service
Listen: /run/acpid.socket (Stream)
Jun 07 23:42:11 jammy-ctn systemd[1]: Listening on ACPID Listen Socket.
Jun 08 00:05:20 jammy-ctn systemd[1]: acpid.socket: Trigger limit hit, refusing further activation.
Jun 08 00:05:20 jammy-ctn systemd[1]: acpid.socket: Failed with result 'trigger-limit-hit'.Fortunately, with acpid.socket, the unit hits a limit instead of causing an endless loop.
This problem was initially reported here (https://discuss.linuxcontainers.org/t/odd-behavior-with-ubuntu-22-04-and-lxd-22-04-containers/14275/7) and then here (https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/1977896).
The proposed fix is to add ConditionVirtualization=!container to both acpid.path and acpid.socket same as what was done to acpid.service before.