Bug 86136 - Cannot start new programs
Cannot start new programs
Status: CLOSED DUPLICATE of bug 80358
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2003-03-14 13:06 EST by Philip Ly
Modified: 2007-04-18 12:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-12 02:12:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Philip Ly 2003-03-14 13:06:48 EST
Description of problem:
Occasionally, I am not able to start any NEW program using GNOME MENU. I tried 
starting terminal, nothing happened. I tried TEXT EDITOR, nothing happened. No 
error reported either. Meanwhile, existing running TERMINAL window will 
continue to function properly, but I can't start new ones.

To get out of this condition, I LOGGED OUT, and LOG back in. And then it is 
back to normal, until the next time.

Version-Release number of selected component (if applicable): Red Hat 8.0

How reproducible: 
Not reproducible. Problems happen intermittently several times a day

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Havoc Pennington 2003-03-14 14:29:42 EST
Probably your hostname changes (try typing "hostname") which breaks
~/.Xauthority and ~/.ICEauthority so if you try to start apps you can't
authenticate to the X server. Try running say xterm in an already-open terminal,
if it says can't authenticate this is the problem.

The solution is a better auth mechanism for the X server (one that isn't
hostname sensitive). Perhaps an interesting feature for future releases.

You can workaround it in a totally insecure way by running "xhost +" 
(allows anyone to connect to your X server), this may be safe on single user
systems with a strong firewall. Or you could configure your networking so the
hostname doesn't change.
Comment 2 Mike A. Harris 2003-03-14 14:53:22 EST
We discussed this before I believe, and I investigated the sources.
Whatever changes the hostname is responsible for informing the X server
the hostname has changed and telling the X server to allow connections
from the new hostname.  No changes to XFree86 are required.
Comment 3 Havoc Pennington 2003-03-14 15:05:44 EST
GNOME isn't changing the hostname, and it is a design flaw in the .Xauthority 
stuff that changing the hostname breaks things. It should not be rocket science
to do a better auth scheme if we want to get it on the feature list.

I think we should use this bug as a placeholder for the X authentication
enhancement. If you want to move it to whatever-changes-the-hostname (dhcp?) 
instead, that's fine with me. It's in no way gnome-specific or gnome-related
though. The root problem is X's auth setup, and the hackaround would be 
in the hostname-changing program, neither of those are GNOME.
Comment 5 Philip Ly 2003-03-17 09:44:41 EST
Thank you for the input. In my case, I did change the hostname, though the 
problem did not seem to happen immediately after that, but randomly later. I 
have reconfigured my Network with the new hostname permanently, and so I shall 
see if the problem goes away. THnks.
Comment 7 Mike A. Harris 2005-04-20 11:07:44 EDT

*** This bug has been marked as a duplicate of 80358 ***

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