Dokumenty<Poprzedni | Spis treści | Następne>
6.6. Testowanie mechanizmu zrzutu awaryjnego
Testowanie mechanizmu zrzutu awaryjnego spowoduje ponowne uruchomienie systemu. W niektórych sytuacjach może to spowodować utratę danych, jeśli system jest pod dużym obciążeniem. Jeśli chcesz przetestować mechanizm, upewnij się, że system jest na biegu jałowym lub pod bardzo małym obciążeniem.
Sprawdź, czy SysRQ mechanizm jest włączany poprzez sprawdzenie wartości parametru / proc / sys / kernel / sysrq parametr jądra:
cat / proc / sys / kernel / sysrq
Jeśli wartość 0 zwracany jest zrzut, a następnie funkcja ponownego uruchomienia jest wyłączona. Wartość większa niż 1 wskazuje, że włączony jest podzbiór funkcji sysrq. Widzieć /etc/sysctl.d/10-magic-sysrq.conf aby uzyskać szczegółowy opis opcji i wartości domyślnej. Włącz testowanie zrzutu, a następnie uruchom ponownie za pomocą następującego polecenia:
sudo sysctl -w kernel.sysrq=1
Gdy to zrobisz, musisz zostać rootem, tak jak po prostu używasz sudo nie będzie wystarczające. jako korzeń użytkownik, będziesz musiał wydać polecenie echo c > /proc/sysrq-trigger. Jeśli korzystasz z połączenia sieciowego, utracisz kontakt z systemem. Dlatego lepiej wykonać test będąc podłączonym do konsoli systemowej.
Ma to tę zaletę, że proces zrzutu jądra jest widoczny. Typowy wynik testu powinien wyglądać następująco:
Sudo -s
[sudo] hasło do Ubuntu:
# echo c > /proc/sysrq-trigger
[ | 31.659002] | SysRq: Wywołaj awarię |
[ | 31.659749] | BŁĄD: nie można obsłużyć dereferencji wskaźnika NULL jądra w |
[ | 31.662668] | IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 |
[ | 31.662668] | PGD 3bfb9067 PUD 368a7067 PMD 0 |
[ | 31.662668] | Ups: 0002 [nr 1] SMP |
[ | 31.662668] | CPU 1 |
[ | 31.659002] | SysRq: Wywołaj awarię |
[ | 31.659749] | BŁĄD: nie można obsłużyć dereferencji wskaźnika NULL jądra w |
[ | 31.662668] | IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 |
[ | 31.662668] | PGD 3bfb9067 PUD 368a7067 PMD 0 |
[ | 31.662668] | Ups: 0002 [nr 1] SMP |
[ | 31.662668] | CPU 1 |
(zero)
....
Reszta danych wyjściowych jest obcięta, ale powinieneś zobaczyć ponowne uruchomienie systemu i gdzieś w dzienniku zobaczysz następujący wiersz:
Rozpocznij: Zapisywanie vmcore przed awarią jądra...
Po zakończeniu system uruchomi się ponownie i powróci do normalnego trybu operacyjnego. Następnie znajdziesz plik Kernel Crash Dump i powiązane podkatalogi w folderze /var/awaria katalog:
ls /var/crash
201809240744 kexec_cmd linux-image-4.15.0-34-generic-201809240744.crash
Jeśli zrzut nie działa z powodu błędu OOM (Out Of Memory), spróbuj zwiększyć ilość zarezerwowanej pamięci poprzez edycję /etc/default/grub.d/kdump-tools.cfg. Na przykład, aby zarezerwować 512 megabajtów:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT jądro awarii=384M-:512M"
biegać sudo update-grub a następnie uruchom ponownie komputer i ponownie przetestuj.