On Wed, 05 Nov 2014 14:52:27 +0100 Michael Biebl <bi...@debian.org> wrote: > Am 05.11.2014 um 14:25 schrieb Norbert Preining: > > Hi TEd, hi Michael (Meskes), > > > >> override_dh_systemd_enable: > >> dh_systemd_enable --no-enable debian/acpid.service > >> dh_systemd_enable debian/acpid.socket > > > > That --no-enable should probably removed in the rules file. > > There are more kernel modules out there (thinkpad?...) that > > send acpi events via the kernel, thus not starting the > > acpid would disable all of them. > > Well, the kernel events are not disabled if acpid is not running. I > think what you meant can be summarised as: > > There are different use cases for acpid: > a/ dispatching acpi events via /run/acpid.socket. Those events are > consumed by 3rd party applications which read from the socket file. > Using systemd socket activation means, acpid is only started on demand > if there is actually a consumer requiring acpid. > E.g. traditionally, this was the way, Xorg read ACPI events. > > b/ acpid's internal event processing which calls (shell) scripts on > certain events which are defined in /etc/acpi/. > > > I assume Norbert is using acpid in mode b/, so what he noticed was, that > his shell scripts in /etc/acpi/ were not processed as he apparently > doesn't have a service which triggers the start of acpid by reading from > /run/acpid.socket.
If acpid needs to run to manage scripts in /etc/acpi/events/, then in addition to the acpid.socket file, you should also ship an acpid.path file, containing: [Path] ConditionDirectoryNotEmpty=/etc/acpi/events/ [Install] WantedBy=paths.target That will then cause systemd to automatically activate acpid.service whenever /etc/acpi/events/ becomes non-empty, in addition to acpid.socket which will activate acpid.service whenever anything connects to the acpid socket. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
