Fedora 17: Freezes completely on a regular basis

[stzahi]

Hi,
I had the same problem,
It happent to me because I've synced my fedora Gnome with my gmail contacts (over 2000 contacts)
and therefor my fedora was freezing while trying to catch all my contacts.
The minute I've canceled it all returned working fine.

good luck!

[Randall Bingham]

Originally Posted by tashirosgt

There are lots of random things you can try such as switching the brand of mice that you use (if it's a desktop machine). My FC 16 and 17 desktops don't work with the iOne brand USB mice that I own. They work with lenovo (IBM) mice.

You can try to do a rational diagnosis of the problem. (This does not always succeed!) That would involve examining your log files (/var/log/* and /home/*/.xsession-errors). If you get really hard freezes you might have to enable the SYSRQ key to proceed.

The term "freeze" is ambiguous. There are various degrees of freezes. One simple way to divide freezes is that in some cases the nulock led on the keyboard works when the numlock key is pressed and in others it doesn't. In some cases, CTRL-ALT-F2 brings up a console and in others it doesn't.

When mine Froze last I did try CTRL-ALT-F2 and nothing happened. I had to push reset and reboot. I do not know what enabling the SYSRO key means. I am still quite new to this. I wouldn't know what to look for by examining my log files or even where to find them.

[marko]

Originally Posted by Randall Bingham

When mine Froze last I did try CTRL-ALT-F2 and nothing happened. I had to push reset and reboot. I do not know what enabling the SYSRO key means. I am still quite new to this. I wouldn't know what to look for by examining my log files or even where to find them.

He didn't write SYSRO but rather SYSRQ (note the Q and not O), that's the key just above the Insert key on the standard keyboard. That is the "System Request" key, it was originally used in the old mainframe days but Linux it's used to control the kernel even when normal access to the kernel (like a command window) will not work.

The default in /proc/sys/kernel/sysrq is "0" which has Sysrq support disabled, but the second reference above shows that if you put "1" in there, all the codes will be enabled or you can enable any combination of these eight options:

2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signalling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all RT tasks

so if you want to enable only reboot/poweroff, you'd do:

echo "128" > /proc/sys/kernel/sysrq

via the rc-local.service

As to how to use it, the best reference seems to be the second URL below:

REF:
http://en.wikipedia.org/wiki/Magic_SysRq_key
http://www.kernel.org/doc/Documentation/sysrq.txt

[tashirosgt]

Originally Posted by Randall Bingham

I wouldn't know what to look for by examining my log files or even where to find them.

Don't worry about interpretation. I haven't met anybody who could interpret every message in a log file. You can always post the log file to the forum and have other people look at it. As I said, the main log files are in the /var/log/ directory and if you have an unfrozen syatem, you can look at them with whatever application the file browser brings up. If you use a terminal you can look at them with the command called "less".

For example, as an ordinary user do

cd
less .xsession-errors

Use the up and down arrows to navigate. Use 'q' to quit. Use 'g' to the start of the file and 'G" to go to the end of it.

As root, do

less /var/log/messages

[davidoff]

(imsettings-check:1263): GLib-WARNING **: (gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)

(imsettings-check:1284): GLib-WARNING **: (gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)

(imsettings-check:1292): GLib-WARNING **: (gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)
/usr/bin/startxfce4: X server already running on display :0
ssh-agent is already running; starting gpg-agent without ssh support
xfdesktop[1347]: starting up
xfce4-settings-helper: Another instance is already running. Leaving...

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:56:19: Not using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:56:21: Not using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:267:19: Not using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:267:21: No
t using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:297:19: Not using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:297:21: Not using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:323:19: Not using units is deprecated. Assuming 'px'.

(bluetooth-applet:1364): Gtk-WARNING **: Theme parsing error: gtk.css:323:21: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:56:19: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:56:21: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:267:19: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:267:21: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:297:19: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:297:21: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:323:19: Not using units is deprecated. Assuming 'px'.

(nm-applet:1429): Gtk-WARNING **: Theme parsing error: gtk.css:323:21: Not using units is deprecated. Assuming 'px'.
** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area
WARNING: gnome-keyring:: couldn't connect to: /run/user/michael/keyring-2BK5Hj/pkcs11: No such file or directory
~
~
~
~
~
(END)

[TiredTreads]

To resolve speed issues in firefox and linux in general this is the definitive guide.

linuxandfirefoxslow.blogspot.com

It's not the code, it's how linux sees the web. Trick is making sure to remove all the piece that hang the web.

[tashirosgt]

davidoff,

I don't see any serious errors in the log you posted. Was this from a session where your machine froze? To get the .xsession-log from a session where your machine freezes, you'll have to break out of the freeze somehow. That's why the system request key is useful.

In the /var/log directory, there are not only logs for the current session, but logs for past sessions, so if you have a freeze and can't break out except by powering-off or using reset, you may still find a log for the session that had the freeze. It's important to note the dates and times of a freeze when you go hunting for relevant logs since this information shows which files may record it.

When programs crash, they may create a directory in /var/spool/abrt that contains information about the crash. The directories' names indicated the crashed program and the date and time. In each directory are files that have information about the crash. See if your freezes correspond to a particular program crashing.

[Boina Roja]

Originally Posted by george_toolan

That's a feature and not a bug. The screen will turn off after 10 minutes to save energy ;-)

LOL!!!!!!!!!!!! I guess not everyone cares about the trees!

[hellork]

I had a strange problem where the keyboard would go unresponsive, but the desktop would still sort of work for closing applications, not opening new ones. The suggestions in this thread helped provide reminders. I was running XFCE desktop and had gnome screensaver daemon running. I received a warning about that when I went to change the screensaver settings and it stopped the daemon for me. I went ahead and disabled the XscreenSaver since I don't use it anyway. It (the screen saver) was never coming on which suggests to me that that was the problem (fingers crossed). I thought I had turned it off! I usually do that.

Update: I had run my box completely out of /tmp space.

I deleted some files and a huge video, cleared /tmp and rebooted. All better.

[Valent]

I have a similar issue, my Fedora 17 x86 machine is running on intel i5 with sandybridge, is your the same?
My machine freezes usually when I'm not using it, not while I'm typing and working, but it froze a couple of times while I was working.

It hasn't passed a weekend that I could return on monday and continue to use my machnine, well this was the first monday in months!

I made one simple script that maybe fixed my issue. Feel free to look at my thread and use my script:
http://forums.fedoraforum.org/showthread.php?t=285402

[Valent]

After latest kernel and X update my machine didn't freeze over last weekend! This is first time in months that I had uptime longer than 3-4 days! Uptime was over 7 days.

Is your Fedora now stable?

[jotasan]

Hello guys,

I have more or less the same problem but with the worrying added fact that my SysRq key also becomes unresponsive.
It happens very rarely (once in a month or so) and never following any pattern. I may be using a high demand network simulation application or just browsing Internet. The laptop is just one year old and the problem has been there for months. No apparent overheat (fan speed increase).

I run Fedora 17 in an Acer5755G with a fancy nvidia card which is always causing compatibility problems. I hardly make use of it with the 'optirun' command. Do you think this could affect the system so hard to completely freeze it up?

I have checked the messages log and the xorg error one but, with my limited knowledge, I have seen nothing in the first one while in the second one I one (.xsession-errors) I cant see any time-stamps to locate the freeze moment.

This is the var/log/messages file (attached file). The problem arose at 22:54:01 and I really see nothing strange.

Any help on this or guides on how to investigate it would be really appreciated.
As always, thanks a lot community!

[Valent]

I updated to rawhide kernel and setup kdump per suggestion on Fedora mailing list... let's see what happens over the this weekend.