> Depuis quelques jours, mon syst�me semble r�guli�rement satur�:
> Netscape refuse de fonctionner une fois sur deux, m�me chose pour kmail.
En g�n�ral, `Depuis quelques jours' associ� � `ne fonctionne pas|plus|plus
bien' signifie qu'un param�tre a chang�. En g�n�ral, jusqu'� nouvel avis,
si des applications *non* propri�taires et *simples* (comme Emacs, vi, ls,
df, pine) plantent aussi, cela indique des probl�mes mat�riels. Les
applications plus complexes comme kfm peuvent planter p.ex. si un fichier
d'un type particulier est visible dans le r�pertoire par d�faut de
l'utilisateur ($HOME), cependant ce genre de plantage est syst�matique (cf
exemple 4). Dans ce cas, on peut essayer de d�placer leur r�pertoire de
configuration: mv .kde .kde.DIS, relancer, reconfigurer, voir si
le probl�me se produit aux deuxi�mes et troisi�mes lancements. Si non,
ajouter des configurations au fur-et-�-mesure peut parfois fonctionner.
Quant aux applications propri�taires comme Netscape et Star Office, elles
utilisent souvent des bases de configuration non textuelles, et si elles
sont corrompues (parce que le disque devient plein, ou par un plantage
d'une autre cause dans le logiciel propri�taire) de tels comportements
sont visibles (j'en ai exp�riment�) et presque impossibles � corriger sans
l'effacement de toute les configuration et restauration d'une sauvegarde
(ou r�installation ...).
Des id�es pour debugger ce probl�me serait:
- lancer ces logiciels dans un xterm ou une konsole (sous KDE taper
ALT-F2, puis xterm, puis RETURN, puis taper le nom du logiciel
concern� dans la nouvelle fen�tre). On obtient alors peut-�tre un
peu de debugging en cas de crash. Cf exemple 1. Parfois les logiciels
viennent avec une option de debugging, enfin la commande strace peut
parfois �tre utile (exemple 2).
- lister le contenu du kernel debug ring. En particulier avec les
versions 2.2.14 et inf�rieures (plain; celles de Red Hat je ne sais
pas), il peut arriver des situations o� le VM subsystem (virtual
memory) tue des processus gourmands, cela se voit avec une ligne
du genre `VM: killed netscape' par exemple. D'autres erreurs, y
compris mat�rielles sont en g�n�ral visibles dans ce log. Utiliser
par exemple
dmesg
Ou regarder dans /var/log/messages car le klogd (kernel log daemon)
va transcrire le charabia d'un register dump en noms de fonctions
si le System.map correspond au kernel qui tourne et est situ�
au bon endroit.
> Je viens de faire "xosview" pour voir l'occupation de la m�moire. Je lis
xosview est peut-�tre tr�s joli, mais il ne donne pas des informations
assez d�taill�es � mon go�t. En fait, si l'on regarde en d�tail, en tous
cas chez moi, il affiche en vert la m�moire r�ellement utilis�e, en rouge
la m�moire cache disque qui est allouable pour les applications, et en
bleu vert clair la m�moire gaspill�e.
Il vaut mieux utiliser des commandes de plus bas niveau pour obtenir une
information synth�tique, ou regarder le d�tail par applications (avec ps,
top, ktop, kpm, etc) (cf exemple 3 pour top et free).
Exemple 1:
schaefer@defian:~% netscape
Power failure
Exemple 2:
--- SIGHUP (Hangup) ---
write(11, "\3\0\2\0\311\0\0\4\16\0\2\0\311\0\0\4", 16) = 16
read(11, 0x5001198c, 32) = -1 EAGAIN (Resource temporarily
unavailable)
oldselect(12, [11], NULL, NULL, {0, 0}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, ~[KILL STOP], 8) = 0
gettimeofday({970653386, 992490}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [ILL TRAP SEGV USR2 ALRM CONT TTIN TTOU URG
WINCH RT_4 RT_5 RT_11 RT_12 RT_14 RT_18 RT_21 RT_22 RT_23 RT_28], NULL, 8)
= 0
--- SIGSEGV (Segmentation fault) ---
getpid() = 464
kill(464, SIGBUS) = 0
--- SIGBUS (Bus error) ---
+++ killed by SIGBUS +++
Dans cet exemple, j'envoie un signal HUP � Netscape, et celui-ci se p�te
la gueule avec un SIGSEGV (mais vraisemblablement c'est intentionel).
Exemple 3:
schaefer@defian:~% free
total used free shared buffers cached
Mem: 128360 68136 60224 50768 2636 38248
-/+ buffers/cache: 27252 101108
Swap: 104416 0 104416
schaefer@defian:~%
En appuyant sur SHIFT-M dans top:
12:03pm up 33 min, 4 users, load average: 0.03, 0.01, 0.00
40 processes: 39 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.3% user, 1.9% system, 0.0% nice, 97.6% idle
Mem: 128360K av, 68528K used, 59832K free, 51072K shrd, 2640K buff
Swap: 104416K av, 0K used, 104416K free 38284K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
260 root 6 0 12292 6080 1960 S 0 0.3 4.7 0:12 XF86_SVGA
326 schaefer 0 0 4720 4712 3356 S 0 0.0 3.6 0:01 kfm
280 schaefer 1 0 4136 4128 3008 S 0 0.0 3.2 0:00 kwm
328 schaefer 0 0 4100 4092 2960 S 0 0.0 3.1 0:00 kpanel
347 schaefer 10 10 3860 3852 2876 S N 0 0.0 3.0 0:00 kapm
Exemple 4: ``Comment crasher kfm 1.1.2 et trouver pourquoi''
schaefer@defian:~% ln -s ~/SOUNDS/grabbin/abba_gold_1/MP3/track01.cdda.wav.mp3
index.html
Ensuite cliquer sur kfm et aller dans le home-directory. Pouf. La premi�re
fois �a tue kfm, alors profiter de le relancer dans un xterm:
schaefer@defian:~% kfm
Could not read '/tmp//kfm-cache-1000/index.txt'
Segmentation fault
Aha, donc il re�oit un signal SEGV. Regardons quels fichiers sont lus
en dernier:
schaefer@defian:~% strace -f -e open kfm 2> /tmp/a1
schaefer@defian:~% grep open /tmp/a1 | tail -1
[pid 594] open("/home/schaefer/index.html", O_RDONLY) = 11
--
Marc Schaefer
Chinasol, Almu�ecar.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
