Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 613315 - kernel-2.6.35 no longer creates /proc/acpi/event, which breaks /etc/rc.d/init.d/acpid
kernel-2.6.35 no longer creates /proc/acpi/event, which breaks /etc/rc.d/init...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: acpid (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Jiri Skala
Fedora Extras Quality Assurance
:
: 613297 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-10 14:30 EDT by Gene Snider
Modified: 2014-11-09 17:33 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-13 01:55:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gene Snider 2010-07-10 14:30:08 EDT
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:
Comment 1 Gene Snider 2010-07-10 15:05:21 EDT
Oops, make that comment about failing read kernel-2.6.35, not kernel-2.6.45.

Gene
Comment 2 Gene Snider 2010-07-11 17:19:43 EDT
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
Comment 3 Gene Snider 2010-07-11 18:38:21 EDT
This bug should have been reported against:

acpid-2.0.4-1.fc14.x86_64 : ACPI Event Daemon

Sorry about that,
Gene
Comment 4 Ted Felix 2010-07-11 19:36:40 EDT
  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.
Comment 5 Jiri Skala 2010-07-12 02:53:44 EDT
*** Bug 613297 has been marked as a duplicate of this bug. ***
Comment 6 Ted Felix 2010-07-12 15:58:48 EDT
  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.
Comment 7 Jiri Skala 2010-07-13 01:55:53 EDT
Thanks Ted for recommendation. This change currently is available in rawhide repository.

Note You need to log in before you can comment on or make changes to this bug.