Bug 61290 - halt after su breaks with GTK+ error
Summary: halt after su breaks with GTK+ error
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: usermode   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-03-16 03:19 UTC by Pete Zaitcev
Modified: 2007-04-18 16:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-27 21:34:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Pete Zaitcev 2002-03-16 03:19:31 UTC
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
[root@elanor zaitcev]# rpm -qf /usr/bin/halt
[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-16 03:45:48 UTC
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 21:49:12 UTC
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 21:34:11 UTC
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.