Le applicazioni vengono chiuse in modo inatteso sotto Ubuntu

2

Sto usando Ubuntu e talvolta quando il sistema sotto carico una delle applicazioni scompare per qualche motivo. Di solito è Firefox ma succede anche ad altre applicazioni. Non ci sono log in syslog e nessun messaggio di errore viene mostrato.

Quale può essere la ragione di tale comportamento, come posso eseguire il debug della situazione e risolverlo, quindi tutte le mie applicazioni rimangono intatte?

Aggiornare: Ho trovato il seguente in syslog, non so come interpretarlo però :)

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

... e sta succedendo per un paio di pagine in più.

linux ubuntu

— vava
fonte

3

Ti suggerisco di esaminare le opzioni dettagliate per ciascuna di queste applicazioni e avviarle manualmente tramite terminale anziché attraverso il menu di Gnome o lanciatori come Gnome-Do.

per esempio

$ nohup app-to-debug --option1 --verbose 1 & gt; app-to-debug1.log 2 & gt; & amp; 1 & amp;

Questo assicura che qualsiasi messaggio lanciato dall'app, esegua il debug o altro, venga catturato in un log.

Stai vedendo un kernel oops:

Oops: 0000 [#1] SMP

Linux Kernel oops :

Un oops è una deviazione dal corretto comportamento del kernel di Linux che produce un determinato registro degli errori. Il condizioni di panico del kernel più note risultati da molti tipi di oops, ma altri potrebbero consentire il funzionamento continuato con affidabilità compromessa. Il termine non rappresenta niente, altro di un semplice errore.

Quando il kernel rileva un problema, lo fa stampa un messaggio oops e ne uccide processo incriminato.

— nagul
fonte

Eh, bello sapere ma non aiuta molto :)

— vava

@vava - Sì, non risolve il problema. Otoh, il kernel oops non è generalmente facile da eseguire il debug. Cerca i messaggi oops e potresti trovare qualcosa, ma sarebbe comunque un'ipotesi al meglio.

— nagul

1

C'è uno strumento strace in ogni distribuzione Linux, per rintracciare le chiamate di sistema. Questa potrebbe essere una delle soluzioni per vedere cosa sta succedendo con l'app.

Basta eseguire Firefox e vedere quali risultati ti daranno strace dopo che Firefox si sarà interrotto inaspettatamente.

$ strace <name of the program>

— Andrejs Cainikovs
fonte

Si scopre che non è una buona idea :) Firefox si è bloccato con X Window quando ho provato ad avviarlo. Ucciderlo dalla console fa scoppiare tutto.

— vava

In quel caso, sembra che il tuo sistema non stia affrontando il carico. Suggerirei di aggiornare la RAM.

Bene, la maggior parte della RAM è occupata dalla cache, quindi non penso che non ci sia un coping. Lo scambio è a malapena usato :)

— vava

0

Mi sembra che tu stia correndo nel (in) famoso OOM (esaurimento della memoria) Killer . Quando il sistema esaurisce la memoria libera, il kernel sceglie un processo che utilizza una grande quantità di memoria e lo uccide. Questo è un male necessario per mantenere in esecuzione altri processi.

Questa pagina ha alcuni suggerimenti utili per capire come funziona il killer OOM e modificarne il comportamento.

— John Ledbetter
fonte

1

Se il oom-killer fosse al lavoro, non vedresti una voce in / var / log / syslog? L'OP non vede errori in syslog.

— nagul

Sì, hai ragione - mi sono perso. Di solito ci sono alcune righe nel syslog relative al oom-killer.

— John Ledbetter

Grazie, in realtà stavo sospettando quella funzionalità, ma ho completamente dimenticato come viene chiamato. Ora posso grep un syslog per vedere se è questa cosa :)

— vava

BTW c'è qualcosa di simile ma per carico del processore? Che uccide i processi che utilizzano troppa CPU per troppo tempo? Sembra proprio un lavoro di tale sottosistema :)

— vava

No, non c'è un processo simile per il carico della CPU, per quanto ne so. Quando si esaurisce la memoria, è una condizione catastrofica. Se la tua CPU è ancorata, significa solo che le cose impiegheranno più tempo per terminare la corsa.

— John Ledbetter

0

Ti suggerirei di installare memtest86+ (disponibile dal menu di avvio di Grub dopo l'installazione) e controllare se la memoria è a posto.

— Grumbel
fonte