Wyszukiwanie w witrynie

Seria RHCSA: Zarządzanie procesami w RHEL 7: uruchamianie, zamykanie i wszystko pomiędzy – część 5


Zaczniemy ten artykuł od ogólnego i krótkiego przeglądu tego, co dzieje się od momentu naciśnięcia przycisku Zasilanie w celu włączenia serwera RHEL 7 do momentu wyświetlenia loginu ekranie w interfejsie wiersza poleceń.

Proszę to zanotować:

1. te same podstawowe zasady mają zastosowanie, z być może niewielkimi modyfikacjami, również do innych dystrybucji Linuksa i
2. poniższy opis nie ma na celu przedstawienia wyczerpującego wyjaśnienia procesu uruchamiania, a jedynie przedstawienie podstaw.

Proces uruchamiania systemu Linux

1. POST (samotest po włączeniu zasilania) inicjuje i przeprowadza kontrolę sprzętu.

2. Po zakończeniu POST kontrola systemu jest przekazywana do programu ładującego pierwszego stopnia, który jest przechowywany w sektorze rozruchowym jednego z dysków twardych (w przypadku starszych systemy korzystające z BIOS-u i MBR) lub dedykowaną partycję (U)EFI.

3. Program startowy pierwszego etapu ładuje następnie program startowy drugiego etapu, najczęściej GRUB (GRand Unified Boot Loader), który znajduje się w 3./boot, który z kolei ładuje jądro i początkowy system plików oparty na pamięci RAM (znany również jako initramfs, który zawiera programy i pliki binarne wykonujące niezbędne działania potrzebne do ostatecznego zamontuj rzeczywisty główny system plików).

4. Wyświetlany jest ekran powitalny, który pozwala nam wybrać system operacyjny i jądro do uruchomienia:

5. Jądro konfiguruje sprzęt podłączony do systemu i po zamontowaniu głównego systemu plików uruchamia proces z PID 1, który z kolei inicjuje inne procesy i prezentuje nas z prośbą o zalogowanie się.

Uwaga: jeśli chcemy to zrobić później, możemy sprawdzić specyfikę tego procesu za pomocą polecenia dmesg i filtrować jego dane wyjściowe za pomocą narzędzi, które możemy wyjaśniliśmy w poprzednich artykułach z tej serii.

W powyższym przykładzie użyliśmy dobrze znanego polecenie ps, aby wyświetlić listę bieżących procesów, których proces nadrzędny (lub innymi słowy proces, który je uruchomił) jest usystematyzowany (menedżer systemu i usług, na który przełączyła się większość nowoczesnych dystrybucji Linuksa) podczas uruchamiania systemu:

ps -o ppid,pid,uname,comm --ppid=1

Pamiętaj, że flaga -o (skrót od –format) pozwala zaprezentować wynik ps w niestandardowym formacie odpowiadającym Twoim potrzebom za pomocą słowa kluczowe określone w sekcji SPECYFIKATORY FORMATU STANDARDOWEGO w man ps.

Innym przypadkiem, w którym będziesz chciał zdefiniować wyjście ps zamiast korzystać z wartości domyślnych, jest sytuacja, gdy musisz znaleźć procesy powodujące znaczne obciążenie procesora i/lub pamięci i odpowiednio je posortować:

ps aux --sort=+pcpu              # Sort by %CPU (ascending)
ps aux --sort=-pcpu              # Sort by %CPU (descending)
ps aux --sort=+pmem              # Sort by %MEM (ascending)
ps aux --sort=-pmem              # Sort by %MEM (descending)
ps aux --sort=+pcpu,-pmem        # Combine sort by %CPU (ascending) and %MEM (descending)

Wprowadzenie do SystemD

Niewiele decyzji w świecie Linuksa wywołało więcej kontrowersji niż przyjęcie systemd przez główne dystrybucje Linuksa. Zwolennicy Systemda jako jego główne zalety wymieniają następujące fakty:

Przeczytaj także: Historia „init” i „systemd”

1. Systemd umożliwia równoległe wykonywanie większej liczby procesów podczas uruchamiania systemu (w przeciwieństwie do starszego SysVinit, który zawsze jest wolniejszy, ponieważ uruchamia procesy jeden po drugim, sprawdza jeśli jeden jest zależny od drugiego, a następnie czeka na uruchomienie demonów, aby można było uruchomić więcej usług) oraz

2. Działa jako dynamiczne zarządzanie zasobami w działającym systemie. W ten sposób usługi są uruchamiane w razie potrzeby (aby uniknąć zużywania zasobów systemowych, jeśli nie są używane), a nie uruchamiane bez ważnego powodu podczas rozruchu.

3. Wsteczna kompatybilność ze skryptami SysVinit.

Systemd jest kontrolowany przez narzędzie systemctl. Jeśli masz doświadczenie w SysVinit, prawdopodobnie znasz:

  1. narzędzie serwisowe, które w starszych systemach służyło do zarządzania skryptami SysVinit, oraz
  2. narzędzie chkconfig, które służyło do aktualizowania i sprawdzania informacji o poziomie działania usług systemowych.
  3. zamknięcie, którego musiałeś użyć kilka razy, aby ponownie uruchomić lub zatrzymać działający system.

Poniższa tabela pokazuje podobieństwa między użyciem tych starszych narzędzi a systemctl:

Legacy tool Systemctl equivalent Description
service name start systemctl start name Start name (where name is a service)
service name stop systemctl stop name Stop name
service name condrestart systemctl try-restart name Restarts name (if it’s already running)
service name restart systemctl restart name Restarts name
service name reload systemctl reload name Reloads the configuration for name
service name status systemctl status name Displays the current status of name
service –status-all systemctl Displays the status of all current services
chkconfig name on systemctl enable name Enable name to run on startup as specified in the unit file (the file to which the symlink points). The process of enabling or disabling a service to start automatically on boot consists in adding or removing symbolic links inside the /etc/systemd/system directory.
chkconfig name off systemctl disable name Disables name to run on startup as specified in the unit file (the file to which the symlink points)
chkconfig –list name systemctl is-enabled name Verify whether name (a specific service) is currently enabled
chkconfig –list systemctl –type=service Displays all services and tells whether they are enabled or disabled
shutdown -h now systemctl poweroff Power-off the machine (halt)
shutdown -r now systemctl reboot Reboot the system

Systemd wprowadził także koncepcje jednostek (które mogą być usługą, punktem podłączenia, urządzeniem lub gniazdem sieciowym) i celów (w ten sposób systemd zarządza uruchomieniem kilku powiązanych procesów jednocześnie czasie i można je uważać – choć nie za równe – za odpowiednik poziomów pracy w systemach opartych na SysVinit.

Podsumowując

Inne zadania związane z zarządzaniem procesami obejmują między innymi umiejętność:

1. Dostosuj priorytet wykonania ze względu na wykorzystanie zasobów systemowych procesu:

Osiąga się to za pomocą narzędzia renice, które zmienia priorytet planowania jednego lub większej liczby uruchomionych procesów. Mówiąc najprościej, priorytet planowania to funkcja, która pozwala jądru (obecnemu w wersjach => 2.6) alokować zasoby systemowe zgodnie z przypisanym priorytetem wykonania (czyli uprzejmością, w zakresie od -20 do 19) danego procesu.

Podstawowa składnia słowa renice jest następująca:

renice [-n] priority [-gpu] identifier

W powyższym poleceniu ogólnym pierwszy argument jest wartością priorytetu, która ma zostać użyta, natomiast drugi argument można interpretować jako ID procesu (co jest ustawieniem domyślnym), identyfikator grupy procesów, identyfikator użytkownika lub nazwy użytkowników. Zwykły użytkownik (inny niż root) może jedynie modyfikować priorytet planowania procesu, którego jest właścicielem, a jedynie zwiększać poziom uprzejmości (co oznacza zajmowanie mniej zasobów systemowych).

2. W razie potrzeby zakończ (lub przerwij normalne wykonywanie) procesu:

Mówiąc dokładniej, zabicie procesu uprawnia do wysłania mu sygnału, aby albo bezpiecznie zakończyć jego wykonanie (SIGTERM=15), albo natychmiast (SIGKILL=9) poprzez zabicie lub pkill polecenia.

Różnica między tymi dwoma narzędziami polega na tym, że pierwsze służy do zakończenia określonego procesu lub całej grupy procesów, podczas gdy drugie pozwala zrobić to samo na podstawie nazwy i innych atrybutów.

Ponadto pkill jest dostarczany w pakiecie z pgrep, który pokazuje PID, na które wpłynie użycie pkill. Na przykład przed uruchomieniem:

pkill -u gacanepa

Przydatne może być szybkie sprawdzenie, które PID należą do gacanepa:

pgrep -l -u gacanepa

Domyślnie zarówno kill, jak i pkill wysyłają do procesu sygnał SIGTERM. Jak wspomnieliśmy powyżej, sygnał ten można zignorować (podczas gdy proces kończy swoje wykonywanie lub na dobre), więc jeśli naprawdę musisz zatrzymać działający proces z ważnego powodu, będziesz musiał podać SIGKILL sygnał w linii poleceń:

kill -9 identifier               # Kill a process or a process group
kill -s SIGNAL identifier        # Idem
pkill -s SIGNAL identifier       # Kill a process by name or other attributes 

Wniosek

W tym artykule wyjaśniliśmy podstawy procesu uruchamiania w systemie RHEL 7 i przeanalizowaliśmy niektóre dostępne narzędzia, które pomogą Ci w zarządzaniu procesami przy użyciu popularnych narzędzi i polecenia specyficzne dla systemu.

Pamiętaj, że ta lista nie obejmuje wszystkich ciekawostek związanych z tym tematem, więc możesz dodać do tego artykułu własne preferowane narzędzia i polecenia, korzystając z poniższego formularza komentarza. Pytania i inne uwagi są również mile widziane.