Qu'est ce que watchdog - kworker?

Salut,
ce n’est pas vraiment un problème mais quand même…
Je n’arrive pas à comprendre ce qu’est watchdog à part que c’est un démon qui écrit dans /dev/watchdog. Super.
Pas d’entrée dans le man…

Pour l’histoire, aujourd’hui, j’ai des mini-freezes toutes les 3-4sec. Ca m’est déjà arrivé. Je n’arrive pas très bien à cerner l’origine. Là, je n’ai fait que internet + wine intensif. Une autre fois, ça a été suite à des crash-test de mon porgramme en gtk.
Pour de la bureautique, ça ne gène pas tant que ça mais j’ai toujours de la musique en fond et là c’est l’enfer!

J’ai donc lancé top pour voir. J’ai remarqué watchdog (ou migration et kworker) qui monte à 65% de CPU puis redescend. La commande exacte est de la forme watchdog/0, kworker/0:2 etc…
J’ai rebooté, ça n’a rien changé.

Que fait watchdog? est ce qu’il pourrait être le coupable?

Salut,

Traduction (google + moi) d’une partie de http://www.sat.dundee.ac.uk/psc/watchdog/watchdog-background.html

[quote]Un watchdog en matière d’informatique est quelque chose, généralement basé sur le matériel , qui surveille le comportement «normal» d’un système complexe et si il échoue , effectue une réinitialisation du système pour récupérer un fonctionnement normal .

Vous pouvez en lire plus à ce sujet à l’entrée de Wikipedia sur WDT .

Il est conçu comme un dernier recours pour maintenir la disponibilité d’un système et , à tout le moins , de veiller à ce que l’administrateur puisse se connecter à distance - pour diagnostiquer et corriger les erreurs. Évidemment, il n’empéchera pas une panne matérielle de casser un système , il n’est pas très utile contre un problème de logiciel persistant , mais pour un système qui se comporte généralement bien ( et surtout si il se trouve sur un site distant et / ou critique ), il sert à améliorer la disponibilité globale du système .

Si votre application ne peut pas tolérer une brève interruption de service , un watchdog seul n’apportera aucune solution, vous devez envisager d’autres solutions de haute disponibilité pour le matériel (par exemple RAID pour la protection de l’ erreur de disque ) et le logiciel (clustering et demande la mise en miroir ) qui fournira un degré acceptable de disponibilité globale du système .

Avec le système d’exploitation Linux, il y a deux parties à la surveillance :

- Le module de commande de temporisation matériel et le noyau réel qui peut forcer une réinitialisation matérielle, et ;
- Le démon en espace utilisateur (tache de fond) qui rafraîchit la minuterie et fournit un large éventail de surveillance de la santé et des options de récupération .

Les deux peuvent fonctionner indépendamment , mais il est clair qu’ils sont conçus pour fonctionner ensemble pour une protection maximale .
[…]
[/quote]

J’espère que ça aide…

@+

Salut Elder. Merci pour ta réponse.
Je me suis documenté un peu avec ça: linux.die.net/man/8/watchdog

Donc watchdog est un démon (peut être aussi hardware) qui surveille la santé du système (c’est vague…) et envoie un signal régulier quand tout va bien. Quand ça ne va plus, le watchdog arrête son activité et à ce moment là, il peut se passer un reboot.

Est ce que quelqu’un a ce truc chez lui? Est ce que je peux le virer sans soucis?
C’est infernal, je ne peux plus rien écouter!!

Ci dessous un watchdog minimal qui relance un démon qui s’est arrêté.très efficace si tu n’es pas présent pendant quelques semaines. Ce petit script m’a sorti d’embarras plus d’une fois. Bien évidemment ça n’a rien à voir avec les watchdog au niveau du noyau.

[code]#!/bin/sh
QUI=w | tail -n+3
if [ “$QUI” = “” ] ; then
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/sbin:/sbin"
present()
{
ps $1 > /dev/null
}

LISTE=find /var/run -name "*.pid"
for f in $LISTE ; do
if grep -v $f /var/processusignore > /dev/null ; then
PID=cat $f
for p in $PID ; do
if ! present $p ; then
echo $p “(”$f")" absent
LANCEUR=grep $f /var/processus | awk '{print $2}'
date
echo Relance de $LANCEUR
if [ -z $LANCEUR ] ; then
echo "Pas de moyen de lancer $f"
rm $f
else
logger Relance de $LANCEUR
/etc/init.d/$LANCEUR stop
/etc/init.d/$LANCEUR start
fi
fi
done
fi
done
LISTE2=cat /var/nomprocessus | awk '{print $1}'
for p in $LISTE2 ; do
if ! pidof -x $p > /dev/null ; then
echo $p absent
LANCEUR=grep $p /var/nomprocessus | awk '{print $2}'
date
echo Relance de $LANCEUR
if [ -z $LANCEUR ] ; then
echo "Pas de moyen de lancer $f"
rm $f
else
logger Relance de $LANCEUR
/etc/init.d/$LANCEUR stop
/etc/init.d/$LANCEUR start
fi
fi
done
fi
[/code]

Salut Francois.
Mon problème de départ, c’est des mini-freezes insupportables depuis le début d’aprèm (RàS ce matin!).
top m’indique que ces processus sont présents watchdog, kworker ou migration en plusieurs instances à chaque fois.
Régulièrement, l’un d’entre eux prend 65% du CPU.

J’aimerai savoir pourquoi.

Bon, je suis tombé sur ce fil:
stackoverflow.com/questions/1084 … ker-thread
qui décrit exactement mon problème (voir l’un des derniers post). Un processus kworker qui prend une bonne partie du CPU pendant 1 sec toutes les 5 sec + ce retour de cat:

# cat /proc/18536/stack 18536 étant le pid de l'un des kworker [<ffffffff8105c5c0>] worker_thread+0x140/0x145 [<ffffffff8105c480>] worker_thread+0x0/0x145 [<ffffffff8105f681>] kthread+0x76/0x7e [<ffffffff81356ef4>] kernel_thread_helper+0x4/0x10 [<ffffffff8105f60b>] kthread+0x0/0x7e [<ffffffff81356ef0>] kernel_thread_helper+0x0/0x10 [<ffffffffffffffff>] 0xffffffffffffffff
Apparement, ce kworker répond à une interruption de l’acpi.
Ce qui m’épate c’est que j’ai l’impression que mon problème de freeze est tombé du ciel.

[Edit]: Plus je lis de truc, plus cela semble venir de ma carte graphique intel intégré et d’un problème de noyau.

Salut,

Pour arrêter l’emballement CPU, cette solution a marché pour moi (testing) :

$ sudo ifconfig eth0 down

source : bugs.launchpad.net/ubuntu/+sour … bug/887793

Quant à savoir précisément de quoi il s’agit…

kworker est un processus du noyau et ne peux être supprimé. Il faut voir ce qui le déclenche.

A te lire j’ai l’impression que tu a un problème matériel, genre un condo qui chauffe et qui fait déconner toute ta machine. Je dit condo mais ça peut être tout autre chose, carte graphique/son/reseau, une alim instable, etc.

Pas sûr, je penche également pour le graphisme. Il m’est arrivé sur mon portable (carte intel) d’avoir le processeur qui s’emballe sans que je ne puisse identifier le processus concerné, la solution consiste à faire redémarrer la serveur X (par déconnexion reconnexion), la carte est une Intel. Je n’ai pas approfondi (phénomène très rare) mais je pense que ça vient de là.

En fait, les interrupts pourraient bien venir de ma carte graphique (à priori chauffe puisque le reboot n’avait rien changé) mais je pense que c’est kworker qui gèle momentanément le système en prenant toutes les ressources.
Le gèle n’est pas que graphique. Le son aussi gèle.
Hier, j’ai appliqué le mod widescreen pour baldur’s gate 1 sous wine. C’était super long et j’avais des fixme msvcrt partout. Après ça, les gèles ont empirés pourtant la CG n’était pas sollicitée. Dans le cas d’un chipset graphique integré, la chauffe du processeur peut influencer la carte graphique?

Aujourd’hui tout va bien pour l’instant. Je vais profiter un peu puis je ferai des tests pour tenter de reproduire le truc (surchauffe?, programme qui enclenche les gèles?,…).

Quelques liens intéressants avec des pistes à creuser:
lkml.org/lkml/2011/3/31/68
askubuntu.com/questions/33640/kw … o-much-cpu
askubuntu.com/questions/176565/w … et-so-high

Salut,

kworker est un avatar du kernel himself.
Le tuer n’apparaît pas comme un bonne idée… Si tant est que ce soit possible :confused:
Pour ce qui est du process [watchdog/0] il semble qu’il s’agisse d’un process watchdog propre au kernel.
Le fichier de config du kernel (par défaut) sur une wheezy montre

CONFIG_WATCHDOG=y CONFIG_ITCO_VENDOR_SUPPORT=y --> Qui a un rapport avec le support de timer watchdog pour chipset Intel

Chez moi sur une VM de test (wheezy) sur cpu AMD le process existe mais pas le /dev/watchdog.
Alors que sur le pc que j’utilise pour poster (Intel, Jessie) :

$ ps ax | grep watchdog 10 ? S 0:00 [watchdog/0] 11 ? S 0:00 [watchdog/1] $ ls /dev/ | grep watchdog watchdog watchdog0
Il semblerait (sous réserve de confirmation par un plus barbu que moi) que tes soucis soient liés à ton processeur (température ?)

Essaye de passer un coup d’aspi dans tes ventilos (machine eteinte) je l’ai fait il n’y a pas longtemps et mes machines chauffent beaucoup moins sans la “moquette” :slightly_smiling:

@+

Pour info c’est un portable ? Le ventilo se met bien en route ?

Merci pour vos réponses. Je pensais changer le titre quand j’aurais plus de précision.

C’est un portable Thinkpad X61s donc un petit machin que je fais vivre à la dur.
Le ventilo est apparement très difficile d’accès, il faut tout démonter. Il tourne doucement mais ça ne ventile pas des masses. Si je pousse la machine, le ventilo se met à fond puis finit par redescendre après que la température soit repassée en dessous des 70°C.
Heureusement, le x61 est un portable relativement froid en utilisation normale (par rapport au toshiba avec ati que j’ai connu) donc le ventilo a de la marge.

Pour l’instant kworker/x se tient à carreau (pas plus de 0.3% de tmps en tmps). x est le numéro du coeur apparement.
L’hypothèse la plus probable serait la surchauffe processeur ou gpu.

Je n’ai pas d’aspi sous la main. D’habitude je retirais le tapis à la main après démontage sur les toshiba mais avec le thinkpad c’est plus galère.

@Elder: tu aspires dans quel sens? Le sens normal ou bien tu essaies de refouler la moquette vers le ventilo?

Si tu connais le sens du flux d’air dans le portable tu vas dans le sens inverse (tu aspires par l’entrée d’air) pour que la crasse sorte par là ou elle est venue.
Si tu ne connais pas le sens du flux regarde par les “grilles” et commence par la plus sale.
Il est important que la machine soit complètement éteinte sinon tu peux bousiller un ventilo.

Les Thinkpad, du temps ou IBM les fabriquaient, se démontaient en commençant par le clavier (et, oui, c’était déjà galère !). Depuis que c’est Lenovo, j’ai changer de crémerie.

@+

Attention !!

N’aspirez jamais comme vous le dites un ventilateur de PC. Bloquez le avec un petit fil de fer, un cure dent ou autre avant de passer le coup d’aspirateur.

J’explique : Votre ventilateur est conçu pour tourner à ~1500 tours minute max. Avec un coup d’aspirateur, vous allez le faire tourner beaucoup, mais alors vraiment beaucoup plus vite, et endommager définitivement les roulements à bille de celui ci. C’est pourquoi il faut toujours bloquer un ventilateur avant de l’aspirer.

Tu as très probablement raison sur le principe.
Mais je n’ai jamais eu de problème…
Cela doit dépendre de la qualité des ventilos

@+