MASTER: acpid should be disabled from xorg-server (fedora patch)

[Pauli]

Binary package hint: kdebase-workspace

Xserver tries to connect to acpid.socket very soon after starting. It may fail because acpid is started after X because of missing dependency in upstart job.

This include kdm, gdm and failsafe-X that I have installed. I suspect all others dms are affected too.

ProblemType: Bug
Architecture: i386
Date: Tue Dec 15 09:06:28 2009
DistroRelease: Ubuntu 9.10
Package: kdm 4:4.3.2-0ubuntu7.1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: kdebase-workspace
Uname: Linux 2.6.31-16-generic i686
XsessionErrors: (polkit-gnome-authentication-agent-1:2414): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Scott James Remnant (Canonical) (canonical-scott)]

X doesn't need to connect to the acpid socket, and works fine if it doesn't

[Timo Aaltonen (tjaalton)]

the acpid code should be purged from the server.

[Timo Aaltonen (tjaalton)]

make that "acpi code"

[Mark Shuttleworth (sabdfl)]

Bryce, can you comment on:

 - what X does with acpid.socket
 - what the consequences of missing it on startup would be
 - whether we can drop the acpid.socket lookup at all, or
 - whether we can make X watch /var/run/acpid.socket with inotify and use it if it shows up

Thanks!
Mark

[Bryce Harrington (bryce)]

Hi Mark,

No, xserver does not need acpi to be running. We've known for some time about the error message that gets produced when it isn't there; in fact I had to quell it because it'd spam the Xorg.0.log (see lp #247195). The spamming eventually got fixed upstream, but the acpi probing code (and corresponding error message) is still there.

What the code in question is doing is setting up a listener to acpid for power management events (suspend/resume/battery-status) If it doesn't see acpid at boot, it sets a timer to try again later. So as I understand it, it's not really X *depending* on acpi for anything but rather honoring its presence if it is there.

I checked a recently installed/updated desktop and laptop and see that acpid is still present on both, so assume it's appropriate for X to continue to listen for them. I'm subbing Steve in hopes he understands this notification path better and can shed some light for us.

[Steve Langasek (vorlon)]

Why does the X server care about ACPI events at all, as opposed to input events?

Yes, if X still wants ACPI events, then we're dealing with acpid, for the nonce; I'm just surprised it should need to.

[Bryce Harrington (bryce)]

On Wed, Mar 10, 2010 at 07:10:18PM -0000, Steve Langasek wrote:
> Why does the X server care about ACPI events at all, as opposed to input
> events?

Legacy support?

> Yes, if X still wants ACPI events, then we're dealing with acpid, for
> the nonce; I'm just surprised it should need to.

I guess we could fairly easily just disable it and see if anything
breaks. I can do the patch but I'd like your direction on if this is
sane or not at this point in the release.

[Timo Aaltonen (tjaalton)]

fedora hasn't built the acpi code for some time now:

http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-less-acpi-brokenness.patch?revision=1.1&view=markup

[Bryce Harrington (bryce)]

Heh, I went to package that patch and discovered that I had looked at this patch once before in troubleshooting #439138, but the error message had been just a red herring. Notice especially starting with comment #32 on that bug report a proposal was made to add an acpid dependency but in further investigation this was identified as unnecessary.

That said, I don't have solid opinions one way or another as to whether to keep acpid support enabled in X or not. I no of no issues which would be caused or solved by this change. From what I understand of the code, X may issue this error message but it has timing code to try again later, so if acpid is just late coming up that's totally okay. And if acpid never comes up for whatever reason, it won't break X.

Guidance from Steve Langasek is "unless there's evidence that the change actually fixes something, I think it should be postponed to M". This seems a sensible plan.

Meanwhile, I've packaged the patch and stuck it in a PPA to make it easy for anyone who would like to do some testing with this:
https://edge.launchpad.net/~bryceharrington/+archive/yellow

[Bryce Harrington (bryce)]

Well, if it ain't broke....

Aside the confusing arising from the error message, I don't know of any tangible breakage that removing acpid would solve, so I'm going to leave it alone for now. I think this is a change we could put in for Lucid+1 to give maximum time to test it for regressions. I'll leave it a wishlist bug for now.

[Bryce Harrington (bryce)]

It's been over a year without any indication of a problem that disabling acpid in xserver would solve, so I'm going to close this for now. If anyone can make a case for why to remove it, reopen this bug and let us know.

[Bryce Harrington (bryce)]

(Or if you can't reopen the bug since it's in state wontfix, please file a new bug against xorg-server.)