Błąd „EOF przy odczycie” od klienta

Ten artykuł jest przeznaczony dla Amanda Enterprise (AE)

Problem

  • Podczas uruchamiania tworzenia kopii zapasowej lub sprawdzania hosta klient zgłasza błąd „EOF przy odczycie”. Do klienta można wysłać polecenie ping i ma otwarty port Amanda 10080 (lub port SSH 22, jeśli używa metody uwierzytelniania SSH), ale za każdym razem, gdy wykonywana jest kopia zapasowa lub sprawdzanie hosta, widoczny jest komunikat „EOF on read”.

Błąd

  • W sekcji UWAGI kopii zapasowej raportu z wiadomości e-mail lub w raporcie | Strona zapasowa, zgłaszana jest awaria planera:

BŁĄD: Żądanie planisty do client.zmanda.com nie powiodło się: odczytano EOF z client.zmanda.com

  • Podczas sprawdzania hosta w kopii zapasowej | Na jakiej stronie lub wyjściu amcheck zgłaszany jest następujący błąd:

OSTRZEŻENIE: client.zmanda.com: żądanie samodzielnego sprawdzenia nie powiodło się: odczytano EOF z client.zmanda.com

Przyczyna

Na etapie planowania kopii zapasowej amanda wysyła do klienta żądanie SELFCHECK i SENDSIZE. Pakiet jest odbierany i potwierdzany, ale serwer Amanda Enterprise nigdy nie otrzymuje odpowiedzi ACK i zgłasza EOF w przypadku błędu odczytu. Na kliencie dzienniki wskazują, że klient wysłał odpowiedź SELFCHECK lub SENDSIZE z powrotem do serwera. Istnieją trzy przyczyny tego błędu:

Możliwa przyczyna 1: Podczas sprawdzania hosta klient Amanda sprawdza nazwę hosta i wykonuje odwrotne wyszukiwanie adresu IP. Jeśli żądanie nazwy hosta lub wyszukiwanie wsteczne nie powiedzie się, Amanda nie będzie w stanie uwierzytelnić serwera i zakończy się niepowodzeniem.

Możliwa przyczyna 2: Podczas tworzenia kopii zapasowej Amanda zwraca szacunkowy rozmiar kopii zapasowej w pakiecie SENDSIZE. Ten pakiet jest zwykle większy niż standardowa jednostka MTU wynosząca 1500 bajtów. Jeśli JumboFrames są włączone na serwerze lub kliencie, ale nie na całym sprzęcie sieciowym, pakiet nie zostanie odebrany przez serwer i odrzucony przez sieć.

Możliwa przyczyna 3: W przypadku używania metody uwierzytelniania za pomocą klucza publicznego SSH zamiast standardowej metody uwierzytelniania „bsdtcp” z klientem systemu UNIX lub Linux, uwierzytelnianie SSH kończy się niepowodzeniem podczas sprawdzania hosta i tworzenia kopii zapasowych.

Możliwa przyczyna 4: Twoja polityka SELinuksa na kliencie uniemożliwia Amandzie czytanie z systemu plików.

Rozwiązania

Rozwiązanie powodujące 1: W przypadku błędu Host Check sprawdź, czy możesz przeprowadzić wyszukiwanie do przodu i wstecz serwera Amanda Enterprise na kliencie. Sprawdź, czy nazwa DNS jest tłumaczona na prawidłowy adres IP, a adres IP na prawidłową nazwę hosta. W razie potrzeby dodaj wpisy do plików / etc / hosts, aby poprawić wszelkie rozbieżności.

Rozwiązanie powodujące 2: W przypadku błędu tworzenia kopii zapasowych / planowania należy wyłączyć JumboFrames na kliencie i serwerze lub sprawdzić w zespole ds. Architektury sieci, czy wszystkie elementy sieci mają włączone JumboFrames. Użyj programu Wireshark lub tcpdump, aby sprawdzić, czy pakiet nie jest fragmentowany i upuszczany.

Rozwiązanie powodujące 3: Jeśli ten błąd występuje podczas korzystania z metody uwierzytelniania za pomocą klucza publicznego SSH, zobacz „EOF on read” w przypadku korzystania z metody uwierzytelniania SSH.

Rozwiązanie powodujące 4: Zmodyfikuj swoją politykę SELinux zgodnie z SELinux i Amanda Enterprise artykuł z bazy wiedzy.

pl_PLPolish