On Jan 23, Mattia Dongili <[EMAIL PROTECTED]> wrote: > > to be fixed in X (I suggest by retrying to open the socket if it worked > > the first time). > this is exactely what the patch I submitted here does. But it does only > once, so if the socket is not there on the first retry it'll steal > /proc/acpi/event. Indeed, it's wrong.
> > "breaks unrelated software" is one of the criteria for critical bugs, > > and even if 6.9 needs to move to testing ASAP it's not a reason to take > > this bug lightly. > > > > > 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. > > Wrong, because acpid is normally restarted during the X server life > > cycle (on upgrades and by logrotate) so X needs to cope with it. > > and on some suspend/resume paths to workaround spurious button events. > But who can tell which is the grand-piece-of-sw that has the exclusive > right to open /proc/acpi/event? The one which has been designed to multiplex the events to make them available to other programs, and it's acpid. > BTW: I also submitted a different (more conservative?) patch that simply > drops ACPI support if the socket disappears. So ACPI support in X will randomly break and people will wonder why? (OK, it's still better than breaking acpid.) > So whose bug is this? X. > One could also argue that acpid should handle restart in a smarter way And it would be a waste of our time, because acpid will still be restarted on upgrades. > as closing the socket breaks _all_ "unrelated software" that listens to > it. And the most obvious way to cope with it is to retry immediately and > eventually take /proc/acpi/event if available. Obvious, but wrong. -- ciao, Marco
signature.asc
Description: Digital signature
