Re: The wider implications of dbus breakage
On Fri, Jul 17, 2009 at 03:14:15AM +0200, Michael Biebl wrote: Roger Leigh schrieb: If you run a current unstable system, with a default (empty) xorg.conf this disables C-A-Fn and C-A-Bksp to switch to a virtual terminal or kill a dead X server. I noticed that if you C-A-Bksp disabled by default is an Xorg upstream decision, has nothing to do with D-Bus or HAL or whatever. This is the real breakage here. It's easy for X to leave you no way out, all it takes is a window manager gone apeshit -- or indeed, dbus failing. There are so many window managers and similar creatures in Debian, there's no chance to make them all bug-free no matter how we try. It's unacceptable to leave the user with no choice but a hard reboot -- or even to force them to ssh in if they have sshd installed. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of dbus breakage
Le vendredi 17 juillet 2009 à 11:45 +0200, Adam Borowski a écrit : C-A-Bksp disabled by default is an Xorg upstream decision, has nothing to do with D-Bus or HAL or whatever. This is the real breakage here. It's easy for X to leave you no way out, all it takes is a window manager gone apeshit -- or indeed, dbus failing. There are so many window managers and similar creatures in Debian, there's no chance to make them all bug-free no matter how we try. It's unacceptable to leave the user with no choice but a hard reboot -- or even to force them to ssh in if they have sshd installed. I think it would be nice to re-enable it, but with a less accessible shortcut. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: The wider implications of dbus breakage
On 2009-07-17 11:45 +0200, Adam Borowski wrote: On Fri, Jul 17, 2009 at 03:14:15AM +0200, Michael Biebl wrote: C-A-Bksp disabled by default is an Xorg upstream decision, has nothing to do with D-Bus or HAL or whatever. This is the real breakage here. It's easy for X to leave you no way out, all it takes is a window manager gone apeshit -- or indeed, dbus failing. There are so many window managers and similar creatures in Debian, there's no chance to make them all bug-free no matter how we try. It's unacceptable to leave the user with no choice but a hard reboot -- or even to force them to ssh in if they have sshd installed. Does not help Alt+SysRq+r out of the misery, regaining keyboard control? You should be able to switch to a virtual console then. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The wider implications of dbus breakage
Some people may have recently been bitten by #537125. This mail isn't about that bug in particular, though it did certainly expose the fragility of systems depending upon dbus. If you run a current unstable system, with a default (empty) xorg.conf this disables C-A-Fn and C-A-Bksp to switch to a virtual terminal or kill a dead X server. I noticed that if you run a login manager such as kdm, this is completely dependent upon a working dbus (or a service dependent upon dbus such as hal). With the recent dbus breakage, the login manager stopped working completely, and with no C-A-Fn escape to a virtual console, the system was *completely useless and unrecoverable* unless hard reset and booted into runlevel 1. I was seriously annoyed by this. One userspace service such as dbus or hal, which is not in any way required for fundamental operation of the system, should not be able to turn a working system into a paperweight. We should really be questioning our reliance upon fragile systems such as these, and the implications of what will happen when they break. Leaving a system in a totally unrecoverable state is not acceptable. Again, this isn't about the specific bug. And yes, had I the facility to do so, I could have logged in via the network. However, *unknown future bugs* in these services have the potential to seriously cripple our systems, and we do seem to becoming slowly and unwittingly dependent upon them. That's all, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: The wider implications of dbus breakage
Roger Leigh schrieb: If you run a current unstable system, with a default (empty) xorg.conf this disables C-A-Fn and C-A-Bksp to switch to a virtual terminal or kill a dead X server. I noticed that if you You are mixing a few things here: C-A-Bksp disabled by default is an Xorg upstream decision, has nothing to do with D-Bus or HAL or whatever. No keyboard or mouse if HAL/D-Bus not running. HAL is used for input hotplugging. See [1] for more details. fwiw I heartily agree with you, that if HAL/D-Bus is not available, Xorg should have a safe fallback, so a basic mouse/keyboard setup is always available. I don't find the current behaviour of Xorg reasonable. This is best dealt with in a bug aginst xorg-server though, and not an issue that needs discussing on debian-devel. Cheers, Michael [1] http://wiki.debian.org/XStrikeForce/InputHotplugGuide signature.asc Description: OpenPGP digital signature
