Erreur "EOF en lecture" d'un client

Cet article est pour Amanda Entreprise (AE)

Problème

  • Lors du démarrage d'une sauvegarde ou de l'exécution d'une vérification d'hôte, le client signale une erreur «EOF en lecture». Le client peut recevoir un ping et a le port Amanda 10080 ouvert (ou le port SSH 22 ouvert si vous utilisez la méthode d'authentification SSH) mais à chaque fois qu'une sauvegarde ou une vérification d'hôte est exécutée, «EOF en lecture» est vu.

Erreur

  • Dans la section NOTES d'un rapport de sauvegarde à partir d'un e-mail ou sur le rapport | Page de sauvegarde, un échec du planificateur est signalé:

ERROR: planner Request to client.zmanda.com failed: EOF on read from client.zmanda.com

  • Lors d'un contrôle d'hôte sur la sauvegarde | Quelle page ou quelle sortie amcheck, l'erreur suivante est signalée:

WARNING: client.zmanda.com: selfcheck request failed: EOF on read from client.zmanda.com

Causes

Pendant la phase de planification d'une sauvegarde, amanda envoie une requête SELFCHECK et SENDSIZE au client. Le paquet est reçu et acquitté, mais le serveur Amanda Enterprise ne reçoit jamais de réponse ACK et signale l'EOF en cas d'erreur de lecture. Sur le client, les journaux indiquent que le client a renvoyé la réponse SELFCHECK ou SENDSIZE au serveur. Il y a trois causes de cette erreur:

Cause possible 1: Lors de la vérification de l'hôte, le client Amanda vérifie le nom d'hôte et effectue une recherche inversée de l'adresse IP. Si la demande de nom d'hôte ou la recherche inversée échouent, Amanda ne pourra pas authentifier le serveur et échouera.

Cause possible 2: Pendant la sauvegarde, Amanda renvoie une estimation de la taille de la sauvegarde dans un paquet SENDSIZE. Ce paquet est généralement plus grand que le MTU standard de 1500 octets. Si les JumboFrames sont activées sur le serveur ou le client, mais pas sur tout le matériel du réseau, le paquet ne sera pas reçu par le serveur et abandonné par le réseau.

Cause possible 3: Lors de l'utilisation de la méthode d'authentification par clé publique SSH au lieu de la méthode d'authentification standard «bsdtcp» avec un client UNIX ou Linux, l'authentification SSH échoue lors d'une vérification et d'une sauvegarde d'hôte.

Cause possible 4: Votre politique SELinux sur le client empêche Amanda de lire à partir du système de fichiers.

Solutions

Solution à la cause 1: Pour l'erreur de vérification d'hôte, vérifiez que vous pouvez effectuer une recherche directe et inversée du serveur Amanda Enterprise sur le client. Vérifiez que le nom DNS correspond à l'adresse IP correcte et que l'adresse IP correspond au nom d'hôte correct. Ajoutez des entrées dans les fichiers / etc / hosts si nécessaire pour corriger les écarts.

Solution à la cause 2: Pour l'erreur de sauvegarde / planificateur, désactivez les JumboFrames sur le client et le serveur ou vérifiez auprès de l'équipe d'architecture réseau que tous les éléments du réseau ont les JumboFrames activées. Utilisez Wireshark ou tcpdump pour vérifier que le paquet n'est pas fragmenté et abandonné.

Solution à la cause 3: Lorsque cet échec est observé lors de l'utilisation de la méthode d'authentification par clé publique SSH, veuillez consulter «EOF en lecture» lors de l'utilisation de la méthode d'authentification SSH.

Solution à la cause 4: Modifiez votre politique SELinux conformément au SELinux et Amanda Enterprise article de la base de connaissances.