On Thu, January 12, 2006 1:59 am, martin f krafft said: > Package: xserver-xorg > Version: 6.9.0.dfsg.1-3 > Severity: important > > If Xorg is running, it claims /proc/acpi/events. This causes acpid > to not start: > > lapse:~# /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket > acpid: can't open /proc/acpi/event: Device or resource busy > > Either require acpid and use its socket, or don't lock the ACPI > resource.
No. That's the kernel only supporting a single reader for /proc/acpi/event. I'm cooking a patch to support multiple readers (based on an old and never applied patch) but I doubt it will be accepted mainline. /proc/acpi/event contention has _always_ been a problem and the only solution is to support multiple readers, not to require acpid's socket, that's just ridiculous :) > Note, this is possibly related to bug #345537. The problem did not > exist with 6.8.2, meaning acpid worked fine then. no, 345537 only fixed a bug, xorg was already trying to read acpi events. I's actually just a matter of which process starts first: - acpid: xorgs opens acpid's socket and we all are happy - xorg: xorg takes /proc/acpi/event and nobody else can read from it. With my patch if acpid dies xorg reopens /proc/acpi/event. So, I'd say this is either an acpid bug (start earlier?) or better yet a kernel bug. -- mattia :wq!