Bug 61290 - halt after su breaks with GTK+ error
halt after su breaks with GTK+ error
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: usermode (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-15 22:19 EST by Pete Zaitcev
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-27 16:34:11 EST
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 Pete Zaitcev 2002-03-15 22:19:31 EST
After the last up2date run, the following now happens
when halting a remote machine:

[root@elanor zaitcev]# halt
Gdk-ERROR **: X connection to localhost:10.0 broken (explicit kill or server
shutdown).
[root@elanor zaitcev]# rpm -qf /usr/bin/halt
usermode-1.46-1
[root@elanor zaitcev]# 

This worked before. Please fix it.

[Why the hell halt wants to contact an X server anyway?!
And whose idea was to link halt with GTK?! Tell gnomies
to use gnome-halt or something, so that I can uninstall that.]
Comment 1 Pete Zaitcev 2002-03-15 22:45:48 EST
It seems I am going to eat a crow. The consolehelper is transparent
as designed, and also it's very easy to uninstall the whole usermode RPM.
Alternatively, I can run /sbin/halt directly. So, after a little
RTFMing I managed to halt the box.

It does not change the bug report itself: it worked before,
it does not work anymore. Perhaps the new openssh 3.1p1
started to set $DISPLAY to a bogus value, or something like that.
Comment 2 Jason Tibbitts 2002-04-17 17:49:12 EDT
I have to agree that this is bigtime annoying; I always have to use:

DISPLAY= sudo poweroff

If it doesn't have a server to contact, it does things as expected.

Now, I understand that it's trying to pop up a password dialog, but it's running
as root already!  Why would it need to?  Yes, it can be worked around, but the
fact that it shouldn't be trying to prompt at all makes this a bug.  If it's
deemed that it absolutely must try to prompt, can it be made to continue on as
if DISPLAY is unset when it can't talk to X?
Comment 3 Pete Zaitcev 2003-01-27 16:34:11 EST
I'm not interested in pursuing this, closing. Nalin - two things:
1. Do not leave bugs dangling in NEW state (I'm surprised Dr.Mike
   did not give you a hell for it yet)
2. Fix those gnome-terminal/vte bugs in 8.0.x, it's way more important :)

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