Description of problem: The file /proc/acpi/event was deprecated over two years ago. Apparently, it's been obsoleted in the 2.6.35 kernel. This is the first kernel that the acpi daemon fails to start even though my laptop supports acpi. In order to start acpid at boot or with the service command, I had to comment out the test for /proc/acpi/event. The problem is at line 43: 38 start() { 39 40 check 41 42 # Check for kernel support 43 [ -f /proc/acpi/event ] || exit 1 ## FAILS ON KERNEL-2.6.45 ## 44 45 # Check if it is already running 46 if [ ! -f /var/lock/subsys/acpid ]; then Some other test for acpi kernel support needs to be made for new kernels. Version-Release number of selected component (if applicable): initscripts-9.15-1.fc14 How reproducible: Easily. Steps to Reproduce: 1. Boot kernel-2.6.35, acpid will silently fail 2. Execute "sudo service acpid start", acpid will again fail silently 3. Execute "echo $?" Actual results: acpid fails to start and the exit code is 1. Expected results: acpid starts and exits with code 0. Additional info:
Oops, make that comment about failing read kernel-2.6.35, not kernel-2.6.45. Gene
Just to confirm that the Fedora kernel is obsoleting the file /proc/acpi/event, here are the relevant entries in the kernel configuration files: kernel-2.6.34.1-46.2.7.rc1.fc14: [gene@Mobile-PC kernel-2.6.34]$ grep CONFIG_ACPI_PROC_EVENT *x86* config-x86-generic:CONFIG_ACPI_PROC_EVENT=y config-x86_64-generic:CONFIG_ACPI_PROC_EVENT=y kernel-2.6.35-0.31.rc4.git4.fc14: [gene@Mobile-PC kernel-2.6.35]$ grep CONFIG_ACPI_PROC_EVENT *x86* config-x86-generic:# CONFIG_ACPI_PROC_EVENT is not set config-x86_64-generic:# CONFIG_ACPI_PROC_EVENT is not set From this, it's apparent that the kernel devs have decided to finally obsolete that deprecated file in the 2.6.35 kernel. My current work around is to comment out line 43 in /etc/rc.d/init.d/acpid. This is safe on my system since I know the hardware and new kernel both support acpi. This may not be safe in general. Thanks, Gene
This bug should have been reported against: acpid-2.0.4-1.fc14.x86_64 : ACPI Event Daemon Sorry about that, Gene
While it might be possible to query the kernel somehow to find out whether ACPI information will be coming over netlink, I think it's easier to just remove that test. This is what Debian did. If it is possible to query netlink, then acpid should do it and bow out gracefully if it finds nothing to do on either netlink or the input layer. (I'll put this on my todo and have a look.) Worst case, acpid uses up a little memory. Those who care can turn it off. Ted.
*** Bug 613297 has been marked as a duplicate of this bug. ***
After thinking about this for a while, I've decided that the best policy is to always start acpid at boot and let it run. acpid could be changed to determine whether certain pieces it requires are missing, and decide to exit, however, that's not a good idea. acpid is designed to detect the addition of new event sources that it can use. So, even if there was nothing for it to work with at boot, the user might decide to plug in a USB keyboard later and expect acpid to respond to events from it. (Aside...) Admittedly, some users might not need acpid at all. Those who use KDE or GNOME exclusively have no need for it. So for these users, the memory acpid uses is wasted. I don't feel knowledgeable enough to make the bigger picture call as to whether distros should somehow not install or load acpid if they know an installation is a GNOME-only or KDE-only install. I'll leave that up to the distros to decide. My recommendation: Remove the check for /proc/acpi/event from /etc/rc.d/init.d/acpid and close this bug. Ted.
Thanks Ted for recommendation. This change currently is available in rawhide repository.