Bug 61290

Summary:	halt after su breaks with GTK+ error
Product:	[Retired] Red Hat Linux	Reporter:	Pete Zaitcev <zaitcev>
Component:	usermode	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	j
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-01-27 21:34:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
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-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 :)