Administracja systemu

GNU/Linux Ogólne Przewodnik po rozwiązywaniu problemów dla początkujących

GNU/Linux Ogólne Przewodnik po rozwiązywaniu problemów dla początkujących

W tym przewodniku naszym celem jest poznanie narzędzi i środowiska zapewnianego przez typowy system GNU/Linux, aby móc rozpocząć rozwiązywanie problemów nawet na nieznanym maszynie.
W tym samouczku nauczysz się:

  • Jak sprawdzić miejsce na dysku
  • Jak sprawdzić rozmiar pamięci
  • Jak sprawdzić obciążenie systemu
  • Jak znaleźć i zabić procesy systemowe
  • Jak dzienniki użytkowników, aby znaleźć odpowiednie informacje o rozwiązywaniu problemów systemowych
GNU/Linux Ogólne Przewodnik po rozwiązywaniu problemów dla początkujących

Zastosowane wymagania i konwencje oprogramowania

Wymagania oprogramowania i konwencje linii poleceń Linux
Kategoria Wymagania, konwencje lub wersja oprogramowania
System Ubuntu 20.04, Fedora 31
Oprogramowanie Nie dotyczy
Inny Uprzywilejowany dostęp do systemu Linux jako root lub za pośrednictwem sudo Komenda.
Konwencje # - Wymaga, aby podane polecenia Linux są wykonywane z uprawnieniami root bezpośrednio jako użytkownik root lub za pomocą sudo Komenda
$ - Wymaga, aby podane polecenia Linux zostały wykonane jako zwykły użytkownik niepewny

Wstęp

Chociaż GNU/Linux jest dobrze znany ze swojej stabilności i solidności, są przypadki, w których coś może pójść nie tak. Źródło problemu może być zarówno wewnętrzne, jak i zewnętrzne. Na przykład w systemie może być nieprawidłowy proces, który zjada zasoby lub stary dysk twardy może być wadliwy, co spowoduje zgłoszone błędy we/wy.

W każdym razie musimy wiedzieć, gdzie szukać i co zrobić, aby uzyskać informacje o sytuacji, a ten przewodnik stara się to zapewnić - ogólny sposób na pomylenie tego poszło nie tak. Rozwiązanie każdego problemu zaczyna się od poznania problemu, znalezienia szczegółów, znalezienia pierwotnej przyczyny i rozwiązania. Podobnie jak w przypadku każdego zadania, GNU/Linux zapewnia niezliczone narzędzia, które pomogą postępowi, dotyczy to również rozwiązywania problemów. Kilka następujących wskazówek i metod to tylko kilka typowych, które można zastosować w wielu rozkładach i wersjach.

Objawy

Załóżmy, że mamy ładnego laptopa, nad którym pracujemy. Uruchamia na nim najnowszy Ubuntu, Centos lub Red Hat Linux, a aktualizacje zawsze na miejscu, aby wszystko było świeże. Laptop jest przeznaczony do codziennego użytku ogólnego: przetwarzamy e -maile, rozmawiamy, przeglądamy Internet, być może produkuje na nim niektóre arkusze kalkulacyjne itp. Nic specjalnego nie jest zainstalowane, pakiet biurowy, przeglądarka, klient e -mail i tak dalej. Od jednego dnia do drugiego nagle maszyna staje się bardzo powolna. Pracujemy już nad tym przez około godzinę, więc nie jest to problem po uruchomieniu. Co się dzieje… ?

Sprawdzanie zasobów systemowych

GNU/Linux nie staje się powolny bez powodu. I najprawdopodobniej powie nam, gdzie boli, o ile będzie w stanie odpowiedzieć. Podobnie jak w przypadku każdego programu działającego na komputerze, system operacyjny wykorzystuje zasoby systemowe, a wraz z udziałem osób, które będą musiały poczekać, aż będzie ich wystarczająco dużo, aby kontynuować. To rzeczywiście spowoduje, że odpowiedzi stają się wolniejsze i wolniejsze, więc jeśli występuje problem, zawsze warto sprawdzić stan zasobów systemowych. Zasadniczo nasze (lokalne) zasoby systemowe składają się z dysku, pamięci i procesora. Sprawdźmy je wszystkie.

Miejsca na dysku

Jeśli działający system operacyjny jest poza przestrzenią dysku, to zła wiadomość. Ponieważ uruchomione usługi nie mogą napisać swoich plików logarytmi. Oprócz plików logarytmicznych, gniazd i plików PID (identyfikator procesu) muszą być zapisane na dysku, a chociaż są one małe, jeśli nie ma już przestrzeni, nie można ich utworzyć.

Aby sprawdzić dostępne miejsce na dysku, których możemy użyć df w terminalu i dodaj -H argument, aby zobaczyć wyniki zaokrąglone na megabajty i gigabajty. Dla nas zgłoszeniami są objętości, które wykorzystałyby% 100%. Oznaczałoby to, że dany objętość jest pełna. Poniższe przykładowe dane wyjściowe pokazuje, że mamy w porządku w odniesieniu do miejsca na dysku:

$ df -h Rozmiar systemu plików używany Używany% zamontowany na devTMPFS 1.8G 0 1.8G 0% /Dev TMPFS 1.8G 0 1.8G 0% /dev /sHM TMPFS 1.8G 1.3M 1.8G 1% /run /dev /mapper /lv-root 49G 11G 36G 24% /TMPFS 1.8G 0 1.8G 0% /tmp /dev /sda2 976m 261m 649m 29% /boot /dev /mapper /lv-home 173G 18G 147G 11% /Home TMPFS 361M 4.0k 361m 1%/run/użytkownik/1000
Kopiuj

Mamy więc miejsce na dysku. Zauważ, że w naszym przypadku wolnego laptopa wyczerpanie przestrzeni dyskowej nie będzie podstawową przyczyną. Gdy dyski będą pełne, programy się ulegną lub w ogóle nie zaczną się. W skrajnym przypadku nawet login zawiedzie po uruchomieniu.

Pamięć

Pamięć jest również istotnym zasobem, a jeśli brakuje nam, system operacyjny może wymagać pisania obecnie nieużywanych elementów, aby na dysku tymczasowo (zwane „zamienieniem”), aby przekazać uwolnioną pamięć do następnego procesu, a następnie przeczytaj Wrócił, gdy proces posiadający zamienioną zawartość potrzebuje jej znowu. Cała ta metoda zwana zamianą i rzeczywiście spowolni system, ponieważ pisanie i czytanie do i z dysków są znacznie wolniejsze niż praca w ramach pamięci RAM.

Aby sprawdzić zużycie pamięci, mamy przydatne bezpłatny polecenie, które możemy dołączyć do argumentów, aby zobaczyć wyniki w megabajtach (-M) lub gigabajty (-G):

$ darmowe -m Całkowicie używane bezpłatne udostępniane buff/pamięć podręczna
Kopiuj

W powyższym przykładzie mamy 8 GB pamięci, 1,5 GB za darmo i około 3 GB w pamięci podręcznej. bezpłatny polecenie zapewnia również stan zamieniać: W tym przypadku jest doskonale pusty, co oznacza, że ​​system operacyjny nie musiał pisać żadnej zawartości pamięci na dysku od uruchomienia, nawet na szczytowych obciążeniach. To zwykle oznacza, że ​​mamy więcej pamięci, której faktycznie używamy. Jeśli chodzi o pamięć, jesteśmy bardziej niż dobre, mamy jej mnóstwo.

Obciążenie systemu

Ponieważ procesory wykonują faktyczne obliczenia, czas przetwarzania procesora może ponownie spowodować spowolnienie systemu. Potrzebne obliczenia muszą poczekać, aż jakikolwiek procesor będzie miał czas wolny na ich obliczenie. Najłatwiejszym sposobem zobaczenia obciążenia naszych procesorów jest czas aktu Komenda:

$ Uptime 12:18:24 w górę 4:19, 8 użytkowników, średnia obciążenia: 433, 2 28, 1,37
Kopiuj

Trzy liczby po średniej obciążenia oznaczają średnią w ostatnich 1, 5 i 15 minutach. W tym przykładzie maszyna ma 4 rdzenie procesora, więc staramy się zużywać więcej niż naszą rzeczywistą pojemność. Zauważ również, że wartości historyczne pokazują, że obciążenie znacznie wzrasta w ciągu ostatnich kilku minut. Może znaleźliśmy winowajcę?

Najlepsze procesy konsumenckie

Zobaczmy cały obraz zużycia procesora i pamięci, z najlepszymi procesami wykorzystującymi te zasoby. Możemy wykonać szczyt polecenie, aby zobaczyć ładunek systemu w (bliskim) w czasie rzeczywistym:

Sprawdzanie najlepszych procesów konsumenckich.

Pierwsza linia góry jest identyczna z wyjściem czas aktu, Następnie możemy zobaczyć liczbę, jeśli zadania biegną, śpiące itp. Zwróć uwagę na liczbę procesów zombie (defunkcyjnych); Ten przypadek jest to 0, ale jeśli w stanie Zombie będą pewne procesy, należy je zbadać. Następna linia pokazuje obciążenie procesorów w procentowym procencie i skumulowane odsetki dokładnie Co Procesory są zajęci. Tutaj możemy zobaczyć, że procesory są zajęci obsługą programów przestrzeni użytkowników.

Następnie są dwie linie, które mogą być znane z bezpłatny wyjście, użycie pamięci, jeśli system. Poniżej znajdują się najlepsze procesy, posortowane według użycia procesora. Teraz możemy zobaczyć, co je nasze procesory, w naszym przypadku jest to Firefox.

Sprawdzanie procesów

Skąd mam to wiedzieć, ponieważ najwyższy proces konsumpcji jest wyświetlany jako „treść internetowa” w moim szczyt wyjście? Używając Ps Aby zapytać tabelę procesów, za pomocą PID pokazanego obok górnego procesu, co jest w tym przypadku 5785:

$ ps -ef | GREP 5785 | GREP -V „GREP” Sandmann 5785 2528 19 18:18 TTY2 00:00:54/usr/lib/Firefox/Firefox -ContentProc -Childid 13 -SforBrowser -prefsllen 9825 -PREFMAPSIZE 226230 -PARENTBUILDIDIDIDIDIDIDIDIDIDIDIDIDIDIDIDIDDIDDIDIN. Firefox/przeglądarka 2528 True Tab

Z tym krokiem znaleźliśmy podstawową przyczynę naszej sytuacji. Firefox je czas procesora do tego stopnia, że ​​nasz system zaczyna odpowiadać na nasze działania wolniej. To niekoniecznie wina przeglądarki,
Ponieważ Firefox jest zaprojektowany do wyświetlania stron z sieci World Wide: Aby stworzyć problem procesora w celu demonstracji, wszystko, co zrobiłem, to otwieranie kilkudziesięciu instancji strony testu warunkowego na różnych zakładkach przeglądarki do punktu braku procesora powierzchnie. Więc nie muszę obwiniać mojej przeglądarki, ale mnie za otwieranie stron głodnych zasobów i pozwolić im działać równolegle. Zamykając trochę, mój procesor
Zastosowanie powraca do normy.

Niszczenie procesów

Problem i rozwiązanie są odkryte powyżej, ale co, jeśli nie będę w stanie uzyskać dostępu do przeglądarki, aby zamknąć niektóre zakładki? Powiedzmy, że moja sesja graficzna jest zablokowana i nie mogę się zanotować ani generała
Proces, który Gone Wild nie ma nawet żadnego interfejsu, w którym możemy zmienić swoje zachowanie? W takim przypadku możemy wydać wyłączenie procesu przez system operacyjny. Znamy już pid
Rogue Proces, z którym się dostaliśmy Ps, i możemy użyć zabić polecenie, aby to zamknąć:

$ Kill 5785

Procesy dobrego samopoczucia wyjdą, niektóre mogą nie. Jeśli tak, dodanie -9 Flaga wymusi zakończenie procesu:

$ Kill -9 5785

Należy jednak pamiętać, że może to spowodować utratę danych, ponieważ proces nie ma czasu na zamknięcie otwartych plików lub zakończenie zapisywania wyników w ogóle na dysku. Ale w przypadku pewnego powtarzalnego zadania stabilność systemu może mieć pierwszeństwo przed utratą niektórych naszych wyników.

Znalezienie powiązanych informacji

Współpracowanie z procesami z pewnym rodzajem interfejsu nie zawsze jest przypadkiem, a wiele aplikacji ma tylko podstawowe polecenia, które kontrolują ich zachowanie - mianowicie, uruchom, zatrzymanie, przeładowanie i tym podobne, ponieważ ich wewnętrzne działanie są dostarczane przez ich konfigurację. Powyższy przykład był bardziej pulpitowy, zobaczmy przykład po stronie serwera, w którym mamy problem z serwerem serwisowym.

Załóżmy, że mamy serwer Web, który obsługuje pewne treści dla świata. Jest popularny, więc nie jest to dobra wiadomość, kiedy otrzymujemy telefon, że nasza usługa nie jest dostępna. Możemy sprawdzić stronę internetową w przeglądarce, aby uzyskać komunikat o błędzie z napisem „Nie można się połączyć”. Zobaczmy maszynę, która uruchamia serwer Web!

Sprawdzanie plików dziennika

Nasz komputer hosting WebServer to pudełko Fedora. Jest to ważne ze względu na ścieżki systemu plików, które musimy śledzić. Fedora i wszystkie inne warianty Red Hat przechowują plik dziennika Apache Webserver na ścieżce /var/log/httpd. Tutaj możemy sprawdzić error_log za pomocą pogląd, ale nie znajdź żadnych powiązanych informacji na temat tego, jaki może być problem. Sprawdzanie dzienników dostępu również nie wykazuje żadnych problemów na pierwszy rzut oka, ale dwa razy według myślenia: na serwer WebServer z wystarczającym ruchem Ostatnie wpisy dziennika dostępu powinny być bardzo niedawne, ale ostatni wpis jest już godzinny w wieku. Wiemy z doświadczenia, że ​​strona internetowa przynosi odwiedzających co minutę.

Systemd

Nasza instalacja Fedora używa Systemd jako system init. Zapytajmy o informacje o serwisie WebServer:

# Status Systemctl HTTPD ● HTTPD.Usługa - załadowany serwer Apache HTTP: załadowany (/usr/lib/systemd/system/httpd.praca; wyłączony; PREDETOR PREDET: Wyłączony) Drop-in:/usr/lib/systemd/system/httpd.praca.D └oka Php-Fpm.CON CONT Active: nieudany (wynik: sygnał) od Sun 2020-08-02 19:03:21 Cest; 3min 5s temu Dokumenty: Man: Httpd.Service (8) Proces: 29457 EXECSTART =/usr/sbin/httpd $ Options -dforeground (kod = zabity, sygnał = zabójstwo) główny PID: 29457 (kod = zabity, sygnał = zabójstwo) Status: „Całkowite żądania: 0; /Zajęty pracownicy 100/0; żądania/s: 0; bajty obsługiwane/s: 0 b/s ”CPU: 74 ms 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29665 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29666 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29667 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29668 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29669 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29670 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29671 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29672 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: Proces zabijania 29673 (N/A) z sygnałem Sigkill. 02 sierpnia 19:03:21 MyWebserver1.Foobar Systemd [1]: httpd.Usługa: nie powiodła się z wynikiem „sygnał”.
Kopiuj

Powyższy przykład jest ponownie prosty, The httpd główny proces, ponieważ otrzymał sygnał zabijania. Może być inny sysadmin, który ma do tego zaszczyt, abyśmy mogli sprawdzić, kto
zalogował się (lub był w momencie silnego zamknięcia serwera WebServer) i zapytaj ją o problem (wyrafinowany przystanek serwisowy byłby mniej brutalny, więc musi istnieć powód tego
wydarzenie). Jeśli jesteśmy jedynymi administratorami na serwerze, możemy sprawdzić, skąd pochodzi ten sygnał - możemy mieć problem z naruszeniem lub system operacyjny wysłał sygnał zabójstwa. W obu przypadkach możemy użyć
Plik dziennika serwera, ponieważ ssh Loginy są rejestrowane do dzienników bezpieczeństwa (/var/log/bezpiecznie w przypadku Fedory), a w głównym dzienniku można znaleźć również wpisy audytowe (czyli
/var/log/wiadomości w tym przypadku). Jest wpis, który mówi nam, co się stało w tym drugim:

2 sierpnia 19:03:21 MyWebserver1.Audyt foobar [1]: service_stop PID = 1 UID = 0 auid = 4294967295 ses = 4294967295 msg = "Unit = httpd comm =" Systemd "exe ="/usr/lib/systemd/systemd „hostName = hostName = hostName = hostName =? addr =? terminal =? res = nieudany "

Wniosek

Do celów demonstracyjnych zabiłem główny proces mojego własnego WebServer w tym przykładzie. W numerze związanym z serwerem najlepszą pomocą, jaką możemy uzyskać, jest sprawdzenie plików dziennika i zapytanie o system uruchamiania (lub ich nieobecności) i sprawdzanie ich zgłoszonego stanu, aby zbliżyć się do problemu. Aby to zrobić skutecznie, musimy znać usługi, które prowadzimy: gdzie piszą swoje pliki dziennika, jak
Możemy uzyskać informacje o ich stanie, a wiedza o tym, co jest rejestrowane w normalnych czasach pracy, również bardzo pomaga w identyfikowaniu problemu - może nawet zanim sama usługa wystąpi problemy.

Istnieje wiele narzędzi, które pomagają nam zautomatyzować większość tych rzeczy, takich jak podsystem monitorujący i rozwiązania agregacji dziennika, ale wszystkie zaczynają się od nas, administrator
Pracuj, gdzie i co sprawdzić, czy są zdrowe. Wykazane powyższe proste narzędzia są dostępne w dowolnym dystrybucji, a przy ich pomocy możemy pomóc w rozwiązywaniu problemów z systemami, których nie
nawet zaznajomiony z. To jest zaawansowany poziom rozwiązywania problemów, ale pokazane tutaj narzędzia i ich użycie to niektóre z cegły, które każdy może użyć, aby rozpocząć budowanie umiejętności rozwiązywania problemów na GNU/Linux.

Powiązane samouczki Linux:

  • Rzeczy do zainstalowania na Ubuntu 20.04
  • Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
  • Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
  • Pobierz Linux
  • Rzeczy do zrobienia po zainstalowaniu Ubuntu 22.04 JAMMY Jellyfish…
  • Lista najlepszych narzędzi Kali Linux do testowania penetracji i…
  • Zainstaluj Arch Linux na stacji roboczej VMware
  • Najlepszy Linux Distro dla programistów
  • Linux Pliki konfiguracyjne: Top 30 Najważniejsze
  • Polecenia Linux: Top 20 najważniejsze polecenia, które musisz…