up vote 1 down vote favorite
1
share [g+] share [fb]

I'm running Ubuntu and sometimes when the system under load one of applications just disappear for some reason. Usually it is Firefox but it happens to other applications as well. There's no logs in syslog and no error message is being shown.

What can be the reason of such behaviour, how can I debug the situation and fix it, so all my application stays intact?

Update: I have found the following in syslog, don't know how to interpret it though :)

Sep 17 16:54:03 mobav kernel: [10132.976820] BUG: unable to handle kernel paging
 request at 4d904064
Sep 17 16:54:03 mobav kernel: [10132.976825] IP: [] 0x4d904064
Sep 17 16:54:03 mobav kernel: [10132.976830] *pde = 00000000 
Sep 17 16:54:03 mobav kernel: [10132.976833] Oops: 0000 [#1] SMP 
Sep 17 16:54:03 mobav kernel: [10132.976837] last sysfs file: /sys/devices/pci00
00:00/0000:00:1e.0/0000:14:02.0/rf_kill
Sep 17 16:54:03 mobav kernel: [10132.976841] Dumping ftrace buffer:
Sep 17 16:54:03 mobav kernel: [10132.976843]    (ftrace buffer empty)
Sep 17 16:54:03 mobav kernel: [10132.976845] Modules linked in: tun aes_i586 aes
_generic ieee80211_crypt_ccmp binfmt_misc ppdev radeon drm bridge stp bnep cpufr
eq_stats input_polldev joydev tp_smapi thinkpad_ec acpi_cpufreq uinput lp parpor
t snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_
seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device iTCO_wd
t iTCO_vendor_support thinkpad_acpi ipw2200 intel_agp nsc_ircc psmouse led_class
 agpgart pcspkr ieee80211 ieee80211_crypt video sdhci_pci sdhci serio_raw snd so
undcore snd_page_alloc nvram output btusb irda crc_ccitt reiserfs ohci1394 ieee1
394 tg3 fbcon tileblit font bitblit softcursor
Sep 17 16:54:03 mobav kernel: [10132.976887] 
Sep 17 16:54:03 mobav kernel: [10132.976890] Pid: 4305, comm: multiload-apple No
t tainted (2.6.28-15-generic #50~undervolt2-Ubuntu) 2529FKG

...and it's going on for couple of pages more.

link|improve this question
68% accept rate
feedback

4 Answers

up vote 3 down vote

I'd suggest that you investigate the verbose options for each of these applications, and start them manually via terminal instead of through the Gnome menu or launchers like Gnome-Do.

e.g

$ nohup app-to-debug --option1 --verbose 1>app-to-debug1.log 2>&1 &

This ensures that any message thrown by the app, debug or otherwise, is captured in a log.

You're seeing a kernel oops:

Oops: 0000 [#1] SMP

Linux Kernel oops:

An oops is a deviation from correct behavior of the Linux kernel which produces a certain error log. The better-known kernel panic condition results from many kinds of oops, but others may allow continued operation with compromised reliability. The term does not stand for anything, other than a simple mistake.

When the kernel detects a problem, it prints an oops message and kills any offending process.

link|improve this answer
Huh, nice to know but doesn't help much :) – vava Sep 18 '09 at 1:41
@vava - Yes it doesn't solve the problem. Otoh, kernel oops are generally not easy to debug. Search for the oops messages and you might find something, but it would still be a guess at best. – nagul Sep 18 '09 at 8:10
feedback
up vote 1 down vote

There is strace tool in every Linux distro, for tracing system calls. This may be one of the solutions to see what is going with the app.

Just execute the Firefox and see what results strace will give you after Firefox terminates unexpectedly.

$ strace <name of the program>
link|improve this answer
Turns out this is not such a good idea :) Firefox froze together with all X Window when I tried to start it. Killing it from console unfroze everything. – vava Sep 16 '09 at 12:35
In that case, it sounds like your system is not coping with the load. I'd suggest upgrading the RAM. – Randolph West Sep 16 '09 at 15:26
Well, most of RAM occupied by cache, so I don't think it's not coping. Swap is barely used :) – vava Sep 17 '09 at 0:06
feedback
up vote 0 down vote

It sounds to me like you are running into the (in)famous OOM (out of memory) Killer. When the system runs out of free memory, the kernel picks a process that is using a large amount of memory and kills it. This is a necessary evil to keep other processes running.

This page has some useful tips for understanding how the OOM killer works and changing its behavior.

link|improve this answer
1  
If the oom-killer were at work, wouldn't you see an entry in /var/log/syslog? The OP doesn't see any errors in syslog. – nagul Sep 16 '09 at 18:23
Yes, you're right -- I missed that. There would usually be quite a few lines in the syslog related to the oom-killer. – John Ledbetter Sep 16 '09 at 22:22
Thanks, I was actually suspecting that feature but forgot completely how it is named. Now I can grep a syslog to see if it is this thing :) – vava Sep 17 '09 at 0:23
BTW is there something similar but for processor load? That kills processes that are using too much CPU for too much time? It just looks like a work of such subsystem :) – vava Sep 17 '09 at 1:15
No, there's no similar process for CPU load as far as I know. When you run out of memory, it's a catastrophic condition. If your CPU is pegged, it just means things will take longer to finish running. – John Ledbetter Sep 17 '09 at 15:49
feedback
up vote 0 down vote

I would suggest you install memtest86+ (available from the Grub boot menu after installation) and check if your memory is alright.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.