Heading

System V, systemd i Upstart

Kontrola usług w Linuksie

Proces init

Proces init w systemach Linux jest powszechnie znany jako matka wszystkich procesów. Proces „init” zawsze będzie miał identyfikator procesu „1” (pid of 1), jest to pierwszy proces uruchamiany przez jądro w systemie. init jest skrótem od inicjalizacji i jest używany do uruchamiania wszystkich innych procesów i domyślnego poziomu działania. Z czasem wiele dystrybucji przyjęło standard System V do zarządzania usługami, jednak inne dystrybucje przeszły na „Systemd” lub „Upstart”.

SysV – System V

Jeśli Twoja dystrybucja Linuksa używa standardów „SysV”, init sprawdzi plik o nazwie „/etc/inittab”. Plik ten zawiera Twój domyślny runlevel, pod którym system powinien startować. Na przykład „id:3:initdefault:” automatycznie uruchomi wszystkie skrypty w strukturze katalogów runlevel 3.
Run Level 1 – Tryb pojedynczego użytkownika
Run Level 2 – To samo co runlevel 3, ale bez NFS
Run Level 3 – Tryb wielu użytkowników i sieci
Run Level 4 – Nieużywany
Run Level 5 – To samo co runlevel 3, ale z graficznym pulpitem (X window System)
Więcej informacji na temat procesu bootowania: Booting Linux

Running „System V” init scripts

Dość często jako administrator będziesz potrzebował zatrzymać, uruchomić, zrestartować lub przeładować konkretną usługę/demon. Aby to zrobić używamy polecenia o nazwie „service”. Polecenie to pozwala na wykonanie skryptów „System V”, które zazwyczaj znajdują się w katalogu „/etc/init.d”. Oprócz możliwości uruchomienia i zatrzymania usługi/daemona, możemy również wyświetlić jej aktualny status.

przykłady poleceń service

Sprawdzenie statusu: Tutaj pytamy o aktualny status demona „sshd”

# service sshd statusopenssh-daemon (pid 1599) is running...

Sprawdź status wszystkich procesów: Uruchamia wszystkie twoje skrypty init w kolejności alfabetycznej z opcją statusu. Poniżej znajduje się fragment wyjścia tego polecenia:

# service --status-allabrt-ccpp hook is installedabrtd (pid 1708) is running...abrt-dump-oops (pid 1716) is running...acpid (pid 1487) is running...atd (pid 1740) is running...auditd (pid 1262) is running...automount (pid 1571) is running...avahi-daemon (pid 1375) is running...Usage: /etc/init.d/bluetooth {start|stop}certmonger (pid 1752) is running...cpuspeed is stoppedcrond (pid 1724) is running...cupsd (pid 1476) is running...dnsmasq is stoppedfirstboot is not scheduled to runhald (pid 1496) is running...

Stop: Tutaj zażądaliśmy, aby demon „sshd” został zatrzymany. Opcja status została również wydana, aby sprawdzić nowy status.

# service sshd stopStopping sshd: # service sshd statusopenssh-daemon is stopped

Start: Tym razem żądamy, aby „sshd” został uruchomiony.

# service sshd startStarting sshd: 

Restart: Tym razem zamierzamy „odbić” demona „sshd” (zatrzymać, a następnie natychmiast uruchomić ponownie).

# service sshd restartStopping sshd: Starting sshd: 

Reload: Opcja „reload” jest bardzo przydatna, jeśli dokonałeś zmian w pliku konfiguracyjnym i chcesz wprowadzić te zmiany.

# service sshd reloadReloading sshd: 

Upstart

Upstart jest opartym na zdarzeniach zamiennikiem demona „init”. Upstart został napisany przez byłego pracownika znanej firmy, która dostarcza nam Ubuntu (Canonical). Ideą Upstartu było odejście od tradycyjnego procesu uruchamiania, w którym zadania, które zostały uruchomione musiały zostać zakończone przed rozpoczęciem kolejnego zadania. Upstart jest systemem sterowanym zdarzeniami, co pozwala mu na asynchroniczne reagowanie na zdarzenia systemowe. Upstart jest odpowiedzialny za uruchamianie i zatrzymywanie usług i zadań przy starcie i zamykaniu systemu. Aktywnie monitoruje również te usługi i zadania. Upstart jest również w stanie uruchamiać skrypty sysvinit bez modyfikacji. Różne dystrybucje zawierały Upstart jako zamiennik dla Systemu V. Były to między innymi RHEL, CentOS, Fedora. Jednakże, wiele z tych systemów przeszło na „systemd”
Jak widzieliśmy wcześniej, możemy kontrolować usługi/daemony za pomocą polecenia „service” w Systemie V, jednak w Upstart używamy innego polecenia. Polecenie, które jest używane z Upstartem to „initctl”. Polecenie to pozwala na komunikację z demonem init. Poniżej znajduje się kilka podstawowych przykładów użycia polecenia „initctl”.

przykłady poleceń „initctl”

Sprawdzenie statusu: Opcja ta żąda sprawdzenia statusu określonego zadania.

root@john-desktop:~# initctl status cupscups start/running, process 672

Nazwa zadania jest podawana jako pierwsza, po niej następuje aktualny cel i stan instancji, a następnie numer id procesu.
Stop: Opcja „stop” określa, że pożądany stan powinien być „zatrzymany”.

root@john-desktop:~# initctl stop cupscups stop/waiting

Start: Opcja „start” spowoduje uruchomienie nowej instancji określonego zadania.

root@john-desktop:~# initctl start cupscups start/running, process 3574

Restart: Opcja ta spowoduje, że określone zadanie zostanie ponownie uruchomione. Instancja, która zostanie ponownie uruchomiona zachowa swoją oryginalną konfigurację.

root@john-desktop:~# initctl restart cupscups start/running, process 3606

Reload: Ta opcja spowoduje przeładowanie określonej instancji.

root@john-desktop:~# initctl reload cups

List: List żąda wyświetlenia wszystkich zadań/instancji i ich powiązanego statusu. Poniżej znajduje się przykład z wyjścia tego polecenia:

root@john-desktop:~# initctl listavahi-daemon start/running, process 611mountall-net stop/waitingnmbd stop/waitingpasswd stop/waitingrc stop/waitingrsyslog start/running, process 601tty4 start/running, process 1080udev start/running, process 437upstart-udev-bridge start/running, process 429

Reload Configuration: Ta opcja żąda, aby demon init przeładował swoje pliki konfiguracyjne. Żadne zadania nie są restartowane przez to polecenie.

root@john-desktop:~# initctl reload-configuration cups

W normalnych okolicznościach nie powinno być potrzeby wydawania powyższego polecenia przeładowania, ponieważ „init” obserwuje swoje katalogi konfiguracyjne z „inotify” i automatycznie przeładowuje w przypadku zmiany.

systemd

systemd jest kolejnym zamiennikiem Systemu V. systemd oznacza demona systemowego. Jego nazwa jest celowo pisana małymi literami! systemd został zaprojektowany, aby umożliwić lepszą obsługę zależności i mieć możliwość równoległej obsługi większej ilości zadań przy starcie systemu. systemd obsługuje migawki systemu i przywracanie jego stanu, śledzi procesy przechowywane w tak zwanej „cgroup”, w przeciwieństwie do konwencjonalnej metody „PID”. systemd jest obecnie wykorzystywany w wielu popularnych dystrybucjach Linuksa. Fedora, Mandriva, Mageia, Arch Linux. Istnieją również plany, aby systemd został włączony do nowszych wydań RHEL (Red hat).
Jak widzieliśmy z „System V” i „Upstart” oba typy mają swoje własne unikalne polecenia do kontroli usług. To samo odnosi się do systemd. Polecenie, które jest używane pod systemd jest „systemctl”. Poniżej znajduje się kilka przykładów niektórych podstawowych funkcji polecenia „systemctl”.

polecenie systemd	Opis
systemctl start mytest.service	Uruchamia określoną usługę
systemctl stop mytest.service	Zatrzymuje określoną usługę
systemctl status mytest.service	Zapytaj o status określonej usługi
systemctl list-unit-files –type=service	Wykazuje znane usługi, które można uruchomić lub zatrzymać
systemctl restart mytest.service	Uruchamia, a następnie zatrzymuje określoną usługę
systemctl reload mytest.service	Jeśli obsługiwane, przeładuje pliki konfiguracyjne
systemctl enable mytest.service	Równoważne do chkconfig mytest on
systemctl disable mytest.service	Równoważne do chkconfig mytest off
systemctl is-enabled mytest.service	Sprawdza, czy usługa jest skonfigurowana do uruchamiania w bieżącym poziomie działania