Bonsoir,
Le 01/06/2022 à 06:35, Frédéric a écrit :
> Le mercredi 01 juin 2022, Olivier a écrit :
>
> J'avais immédiatement killé une tache de backup (rdiff-backup), qui avait
> un temps d'utilisation CPU de 10h. Je n'avais pas fait gaffe au process
> state. Là, il est reparti cette nuit, et ce matin, il est en D
> (uninterruptible sleep). Je pense que c'est elle qui merdoie.
>
>> - la machine est configurée avec un DNS qui n'est pas accessible (voir
>> /etc/resolv.conf), ou on lui demande d'accéder à un machine qui n'est
>> pas accessible. Donc il convient de voir si la machine peut bien accéder
>> à son DNS
>>
>> - la machine est configuré pour avoir plusieurs gateway, et au moins une
>> ne marche pas, ou alors les gateway vont dans des réseaux qui ne sont
>> pas communs. Un "route -n" permet de voir cela
>>
>> - une carte réseau est plus ou moins défectueuse. Tu peux utiliser "nc"
>> en mode client et serveur entre la machine et ton laptop
>> https://doc.fedora-fr.org/wiki/Netcat,_connexion_client/serveur_en_bash
>> . Exemple;
>>
>> Sur le serveur:
>>
>> nc -l 2020 > /dev/null
>>
>> Sur ton laptop
>>
>> nc ip_serveur 2020 < /dev/zero
>>
>> Et tu surveilles la bande passante réseau. par exemple, sur le laptop tu
>> lances un "gkrellm" ou un "iftop"
>>
>> Puis tu inverses machines serveur et client
>
> Ok, je ferai ça. Vu que le rdiff-backup semble bizarre, la piste réseau
> est bonne.
>
> Pour info, pas de raid ni de NFS.
Et ton rdiff backup, il passe par quoi excactement ? Le protocole rsync
? Du ssh ? Parce qu'il peut passer aussi par du NFS, et là c'est bingo ! :)
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
