Mamy skrypt bash (wrapper zadania), który zapisuje do pliku, uruchamia zadanie, a następnie przy zakończeniu zadania dołącza do pliku informacje o praca. Owijarka jest uruchamiana na jednym z kilku tysięcy węzłów przetwarzania wsadowego, ale pojawiła się tylko w kilku maszynach wsadowych (uważam, że RHEL6) uzyskujących dostęp do jednego serwera NFS i co najmniej jednej znanej instancji innego zadania wsadowego w innym węźle wsadowym przy użyciu innego Serwer NFS. We wszystkich przypadkach tylko jeden host klienta zapisuje dane pliki. Niektóre zadania trwają kilka godzin, inne trwają minutę.Uszkodzenie losowe w pliku utworzonym/zaktualizowanym ze skryptu powłoki na pojedynczym kliencie na mount NFS
W tym samym okresie, w którym to się wydarzyło, wydaje się, że istnieje 10-50 spraw z ponad 100 000 nowych miejsc pracy.
Oto co wierzę, aby skutecznie być (destylowana) wersja owijki pracy:
#!/bin/bash
## cwd is /nfs/path/to/jobwd
## This file is /nfs/path/to/jobwd/job_wrapper
gotEXIT()
{
## end of script, however gotEXIT is called because we trap EXIT
END="EndTime: `date`\nStatus: Ended”
echo -e "${END}" >> job_info
cat job_info | sendmail [email protected]
}
trap gotEXIT EXIT
function jobSetVar { echo "job.$1: $2" >> job_info; }
export -f jobSetVar
MSG=“${email_metadata}\n${job_metadata}”
echo -e "${MSG}\nStatus: Started" | sendmail [email protected]
echo -e "${MSG}" > job_info
## At the job’s end, the output from `time` command is the first non-corrupt data in job_info
/usr/bin/time -f "Elapsed: %e\nUser: %U\nSystem: %S" -a -o job_info job_command
## 10-360 minutes later…
RC=$?
echo -e "ExitCode: ${RC}" >> job_info
Więc myślę, że istnieją dwie możliwości:
echo -e "${MSG}" > job_info
Komenda ta rzuca z uszkodzonych danych./usr/bin/time -f "Elapsed: %e\nUser: %U\nSystem: %S" -a -o job_info job_commandSpowoduje to uszkodzenie istniejących danych, a następnie prawidłowe wyprowadzenie danych.
Jednak niektóre zadania, ale nie wszystkie, wywołują funkcję jobSetVar, która nie kończy się uszkodzeniem.
Tak więc, kopie w time.c (z GNU czas 1,7), aby zobaczyć, kiedy plik jest otwarty. Podsumowując, time.c jest skutecznie to:
FILE *outfp;
void main (int argc, char** argv) {
const char **command_line;
RESUSE res;
/* internally, getargs opens “job_info”, so outfp = fopen ("job_info", "a”) */
command_line = getargs (argc, argv);
/* run_command doesn't care about outfp */
run_command (command_line, &res);
/* internally, summarize calls fprintf and putc on outfp FILE pointer */
summarize (outfp, output_format, command_line, &res);/
fflush (outfp);
}
więc czas ma FILE *outfp (uchwyt job_info) otworzyć cały czas pracy. Następnie zapisuje podsumowanie na końcu zadania, a następnie faktycznie nie wydaje się, aby zamknąć plik (nie jestem pewien, czy jest to konieczne z fflush?) Nie mam pojęcia, czy bash ma również uchwyt pliku otwarty jednocześnie .
Edycja:
uszkodzonych plików zwykle kończy się składać z uszkodzonej części, a następnie z nie uszkodzonych części, która może wyglądać następująco:
uszkodzonych części, które występują przed non-uszkodzony odcinek jest zazwyczaj głównie pęczek 0x0000, z może pewnym cyklicznego śmieci miesza się:
Oto przykład hexdump:
40000000 00000000 00000000 00000000
00000000 00000000 C8B450AC 772B0000
01000000 00000000 C8B450AC 772B0000
[ 361 x 0x00]
Następnie, na 409. bajt, to nadal z non-uszkodzone części:
Elapsed: 879.07
User: 0.71
System: 31.49
ExitCode: 0
EndTime: Fri Dec 6 15:29:27 PST 2013
Status: Ended
Kolejny plik wygląda tak:
01000000 04000000 805443FC 9D2B0000 E04144FC 9D2B0000 E04144FC 9D2B0000
[96 x 0x00]
[Repeat above 3 times ]
01000000 04000000 805443FC 9D2B0000 E04144FC 9D2B0000 E04144FC 9D2B0000
Obserwowani przez nie uszkodzonych części:
Elapsed: 12621.27
User: 12472.32
System: 40.37
ExitCode: 0
EndTime: Thu Nov 14 08:01:14 PST 2013
Status: Ended
Istnieją inne pliki, które mają o wiele więcej przypadkowych sektorów korupcji, ale więcej niż kilka miało cykliczne cechy podobne do powyższych.
EDYCJA 2: Pierwszy e-mail wysłany z oświadczenia echo -e przechodzi przez prawo. Ostatni e-mail nie zostanie nigdy wysłany z powodu braku metadanych wiadomości e-mail z powodu uszkodzenia. Tak więc MSG nie jest uszkodzony w tym momencie. Zakładamy, że job_info prawdopodobnie nie jest uszkodzony w tym momencie, ale nie byliśmy jeszcze w stanie tego zweryfikować. Jest to system produkcyjny, który nie miał dużych modyfikacji kodu i zweryfikowałem poprzez audyt, że żadne zadania nie zostały uruchomione jednocześnie, co mogłoby dotknąć tego pliku. Problem wydaje się być nieco aktualny (ostatnie 2 miesiące), ale możliwe, że zdarzył się wcześniej i przeszedł. Ten błąd uniemożliwia raportowanie, co oznacza, że zadania są uznawane za zakończone niepowodzeniem, dlatego zwykle są one przesyłane ponownie, ale jeden użytkownik w konkretnym przypadku ma ~ 9 godzin pracy, w których ten błąd jest szczególnie frustrujący. Chciałbym wymyślić więcej informacji lub sposób ich reprodukcji do woli, ale miałem nadzieję, że ktoś może widział podobny problem, szczególnie ostatnio. Nie zarządzam serwerami NFS, ale spróbuję porozmawiać z administratorami, aby zobaczyć, jakie aktualizacje zostały uruchomione przez serwery NFS w czasie tych problemów (jak sądzę RHEL6).
ciekawy efekt! Czy możesz podać przykład tego, jak zwykle wygląda uszkodzony plik? –
Dodałem kilka przykładów. – Brian