Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2smp i686; en-US; 0.8.1) Gecko/20010425 Description of problem: The currently logged in User is effectively logged out and the login screen (Gnome) is presented. This problem is sort of random and occurs when no user is operating at the console, i.e. the problem is generally discovered when returning to hack and finding that the session has been killed. On one occasion (just now) the problem occurred as I was browsing, more specifically while halfway through reading a page on the screen. I have also heard this problem reported by a co-worker. I have no clue on how to reproduce this problem. Suggestions on capturing information that may lead to reproducability will be gratefully received. How reproducible: Didn't try Steps to Reproduce: 1.Install RHL 7.1 2.Login via Gnome login screen. 3.Wait days and days (~6-14) 4.Observe a fresh login screen even though no logout occurred. Additional info: I am aware of this problem occurring on RHL 6.2 as well as 7.1. My system is a dual Xeon with a Viper V550 AGP graphics card. No error messages or system log entries are generated.
Need an X server log from you, and your config file. Please attach each separatly via the file attach link below.
Created attachment 19430 [details] The X Server log (from /var/log/XFree86.0.log)
Created attachment 19431 [details] The XFree86 config file
Created attachment 19432 [details] Just noticed this in /var/log/messages. Note the gnome-name-server exiting.
Created attachment 19433 [details] Ignore last attachment content (didn't save the buffer) :-(
The X server log you've shown is from XFree86 4.x, however your X config file is an XFree86 3.3.6 config file. You need to attach the XFree86 4.x config file, which is XF86Config-4. The /var/log/messages file you've attached shows the following: May 22 03:17:07 hamm rpc.statd[529]: gethostbyname error for ^Xw?^Xw?^Yw?^Yw?^Zw?^Zw?^[w?^[w?%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 That is an attempt by someone to break into your machine using a remote buffer overflow attack against the rpc.statd service. They may or may not have been successful at breaking in, however to ensure this type of threat does not occur in the future, I _strongly_ urge you to run the latest updated packages which Red Hat releases as security and bug fixes to the distribution. You can do this by using the "up2date" command. Also, you should disable any services running on your machine that are not needed and/or not used during normal usage of the machine. rpc.statd is used when using nfs for example, so if you do not use nfs, be sure to disable all nfs related services. It is also strongly recommended to enable a firewall using firewall-config or some other firewall configuration utility - which if configured properly could block attacks like this one. The crashes may or may not be linked to the attack attempt. We have released many updates to Red Hat Linux since the report was filed, including an update to XFree86. If you haven't upgraded already, please upgrade to XFree86-4.1.0-15 as well as any other errata updates not already applied. If this problem persists still, please update this bug report with your current details, including the XF86Config-4 config file, and also a new X server log. If you do have a server crash, make sure you do _not_ start up XFree86 again before copying the log file, as the new X server log will have overwrote the prior logfile thus wiping out any useful crash info. Thanks.
CLosing due to inactivity. If the problem persists, please file a bug report with XFree86 directly at xfree86@xfree86.org, and carbon copy xpert@xfree86.org.