Skip to content

Avoid endless loops when inside a container

Simon Deziel requested to merge sdeziel-guest/acpid:dont-run-inside-container into master

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.

Merge request reports