Wprowadzenie
W informatyce sprawy nie zawsze idą zgodnie z planem. Często nieoczekiwane awarie systemu skłaniają administratorów systemów do inicjowania restartów i ponownego uruchamiania poszczególnych usług. Ustalenie i zrestartowanie każdej usługi, której aplikacja potrzebuje do działania po awarii systemu lub restarcie, może być uciążliwe. W tej pierwszej części dwuczęściowego poradnika pokażemy na praktycznych przykładach, jak skonfigurować usługi, aby uruchamiały się automatycznie po awarii systemu lub restarcie serwera. druga część obejmie informacje teoretyczne o tym, co osiągnęliśmy w części pierwszej.
Użyjemy usługi bazodanowej MySQL do praktycznych przykładów. Jednak te same zasady dotyczą innych procesów składających się na kompletny serwer, takich jak Nginx, Apache, Redis, lub inne aplikacje. Możesz zapoznać się z naszymi poradnikami dotyczącymi jak zainstalować MySQL, Nginx, oraz Apache.
W dystrybucjach Linux istnieją trzy główne systemy inicjalizacji (init), w zależności od uruchomionej dystrybucji. Niektóre dystrybucje mogą być wyposażone w dwa lub więcej systemów init, jak opisano poniżej:
- System V – starszy system init występujący w starszych dystrybucjach, takich jak:
- Ubuntu 9.04 i starsze
- CentOS 5 i starsze
- Debian 6 i starsze
- Upstart – używany w dawnych dystrybucjach, takich jak:
- CentOS 6
- Ubuntu od 9.10 do Ubuntu 14.10 oraz Ubuntu 14.04
- Systemd – używany w najnowszych dystrybucjach, takich jak:
- CentOS 7
- Debian 7 i 8.
- Ubuntu 15.04 i nowsze
Tło
W systemach operacyjnych, a zwłaszcza w systemach Linux i Unix powszechne jest uruchamianie procesów i usług w tle. Takie usługi mogły zostać dostarczone wraz z oprogramowaniem systemu operacyjnego. Niektóre mogły zostać zainstalowane wraz z aplikacjami użytkownika.
Usługi systemu operacyjnego obejmują:
- sshd – to demon umożliwiający połączenia zdalne.
- cupsd – to demon kontrolujący drukowanie.
Zainstalowane usługi aplikacji obejmują:
- httpd/apache2 – usługa dostarczana z serwerem WWW Apache2.
- nginx – usługa dostarczana z serwerem WWW Nginx.
Aby zapewnić dostępność naszych aplikacji internetowych, baz danych, serwerów pocztowych itp., usługi te muszą działać nieprzerwanie. Jeśli jesteś administratorem systemu lub ciekawym programistą aplikacji, chcesz mieć pewność, że takie usługi działają nieprzerwanie, a w niefortunnym przypadku awarii systemu uruchomią się automatycznie po jego restarcie. I dokładnie tego dowiemy się w tym praktycznym poradniku.
Chociaż ustawianie alertów i ciągłe monitorowanie dystrybucji Linuxa jest kluczowe, niektóre usługi Linuxa mogą same się naprawiać, jeśli są dobrze skonfigurowane, dzięki systemom init zarządzającym usługami.
W dystrybucjach Linuxa istnieją tryby pracy realizujące inicjalizację systemu, zwane poziomami uruchomienia (runlevels). Aby usługa uruchamiała się automatycznie, musi zostać dodana do poziomu uruchomienia. Każdy system typu Linux i Unix ma cztery wspólne poziomy uruchomienia, jak wymieniono poniżej:
- 0 – Poziom uruchomienia 0 oznacza zamknięcie systemu.
- 1 – Poziom uruchomienia 1 oznacza tryb jednego użytkownika, tryb ratunkowy.
- 2, 3, 4 – Te poziomy uruchomienia oznaczają stany, w których system został uruchomiony w trybie tekstowym, wieloużytkownikowym z obsługą sieci.
- 5 – Poziom uruchomienia 5 oznacza tryb graficzny, wieloużytkownikowy z obsługą sieci.
- 6 – Poziom uruchomienia 6 oznacza restart systemu.
W tym poradniku dowiesz się, jak skonfigurować usługę Linux, aby uruchamiała się automatycznie po restarcie systemu, korzystając z trzech różnych trybów init wyjaśnionych wcześniej: System V, Upstart i Systemd.
Wymagania wstępne
Ten praktyczny poradnik zakłada, że posiadasz serwer VPS z systemem Linux, którego możesz użyć do wykonywania kroków. Możesz skorzystać z bezpłatnego okresu próbnego w Cloudsigma i uruchomić kilka serwerów, aby wypróbować polecenia. Możesz postępować zgodnie z naszym szczegółowym poradnikiem, jak skonfigurować serwery Ubuntu.
Serwery, które utworzysz w tym poradniku, służą wyłącznie do celów praktycznych i nie należy wypróbowywać tych poleceń na serwerze produkcyjnym, ponieważ wiele usług zostanie zakłóconych.
Niektóre z dystrybucji, których będziesz potrzebować:
- Ubuntu 9.04 i starsze lub Debian 6 x64 (zostaną użyte do zademonstrowania systemu init System V)
- Ubuntu 14.04 x64 (zostanie użyty do zademonstrowania Upstart)
- CentOS 7 x64 (zostanie użyty do zademonstrowania systemd).
Upewnij się, że skonfigurowałeś użytkownika innego niż root z uprawnieniami sudo. Możesz zapoznać się z naszym poradnikiem dotyczącym konfiguracji pliku sudoers tutaj.
Używanie System V
To najstarszy system inicjalizacji (init), który był używany we wcześniejszych dystrybucjach Linuksa, takich jak:
- Debian 6 i starsze
- CentOS 5 i starsze
- Ubuntu 9.04 i starsze
Większość instalowalnych aplikacji serwerowych, takich jak MySQL i Nginx, domyślnie zawiera skrypty init zapisane w katalogu /etc/init.d. Skrypty te umożliwiają ich uruchomienie po restarcie. Mogą jednak nie być skonfigurowane do automatycznego uruchamiania po awarii systemu.
Lista kontrolna automatycznego uruchamiania dla System V
Pierwszym krokiem jest sprawdzenie dostępności funkcjonalnego skryptu init Bash w katalogu /etc/init.d/service. Aby włączyć usługę, w dystrybucjach Debian lub Ubuntu, użyj polecenia update-rc.d, a w systemie CentOS, użyj chkconfig. Zastąp rzeczywistą nazwą swojej usługi:
|
1 |
sudo update-rc.d service enable |
Powyższe polecenie tworzy dowiązanie symboliczne (symlink) w katalogu /etc/rc2.d, które wygląda jak poniższe dane wyjściowe. Nie twórz go samodzielnie, ponieważ jest generowane automatycznie:
|
1 |
lrwxrwxrwx 1 root root 20 Dec 10 07:09 S02mysql -> ../init.d/service |
Na samym dole pliku /etc/inittab dodaj linię respawn, jak pokazano w poniższym ogólnym przykładzie. Pamiętaj, aby zastąpić ją rzeczywistą ścieżką do skryptu startowego Twojej aplikacji:
|
1 |
id:2345:respawn:/bin/sh /path/to/your-application/startup |
Wprowadź następujące polecenia, aby zatrzymać i uruchomić usługę:
|
1 2 |
sudo service service-name stop sudo service service-name start |
Następnie zrestartuj serwer:
|
1 |
sudo reboot |
Jak przetestować zmiany?
Po zrestartowaniu serwera zweryfikuj, czy usługa działa, wyszukując numer procesu za pomocą polecenia:
|
1 |
ps -ef | grep service-name |
Zabij proces za pomocą polecenia:
|
1 |
sudo kill -9 process_number |
Po pięciu minutach zweryfikuj, czy usługa działa i funkcjonuje poprawnie.
Praktyczna konfiguracja System V na przykładzie rzeczywistej usługi
W kolejnych krokach wypróbujemy rzeczywistą aplikację serwerową, taką jak MySQL. Powinieneś mieć dostęp do maszyny wirtualnej z systemem Debian 6. Korzystając z konta z uprawnieniami sudo, połącz się z nią za pomocą SSH lub programu putty jeśli korzystasz z systemu Windows.
Step 1: Install MySQL
Wprowadź następujące polecenie, aby zainstalować MySQL:
|
1 |
sudo apt-get install mysql-server -y |
Po rozpoczęciu instalacji zostaniesz poproszony o hasło użytkownika root. Wprowadź wybrane hasło i potwierdź je. Poczekaj na zakończenie instalacji, a następnie wprowadź następujące polecenie, aby rozpocząć zabezpieczanie MySQL:
|
1 |
mysql_secure_installation |
Zostaniesz poproszony o hasło użytkownika root, które zostało wprowadzone wcześniej. Naciśnij N, aby je zachować. Następnie naciśnij Y, aby zaakceptować kolejne monity dotyczące usuwania anonimowych użytkowników, wyłączenia zdalnego logowania roota i usunięcia testowej bazy danych. Na koniec zaakceptuj przeładowanie tabeli uprawnień, aby zmiany zostały automatycznie zastosowane.
To kończy instalację MySQL. Możesz sprawdzić, czy usługa działa, wprowadzając następujące polecenie:
|
1 |
service mysql status |
Krok 2: Konfiguracja MySQL do automatycznego uruchamiania po restarcie
MySQL jest domyślnie skonfigurowany do uruchamiania po restarcie systemu. Dowiązanie symboliczne do skryptu inicjalizacyjnego MySQL można znaleźć w katalogu /etc/rc2.d. Te dowiązania symboliczne nie są tworzone ręcznie. Możesz użyć polecenia update-rc.d, aby włączać i wyłączać usługi.
Wprowadź następujące polecenie, aby wyświetlić zawartość katalogu:
|
1 |
ls -l /etc/rc2.d |
Sprawdź, czy widzisz dowiązanie symboliczne do skryptu init MySQL:
|
1 |
lrwxrwxrwx 1 root root 15 Dec 2 10:42 S01mysql -> ../init.d/mysql |
Litera S jest ważna, ponieważ dopóki widzisz S skrypt w domyślnym katalogu poziomu uruchamiania (runlevel) dla usługi, system init uruchomi usługę podczas uruchamiania serwera. Aby zweryfikować, czy MySQL uruchomi się automatycznie po restarcie, wprowadź następujące polecenie, aby zrestartować system:
|
1 |
sudo reboot |
Twoje połączenie SSH zostanie przerwane podczas restartu. Odczekaj minutę lub dwie i połącz się ponownie. Uruchom następujące polecenie, aby sprawdzić, czy usługa działa:
|
1 |
service mysql status |
Wynik wskaże, że usługa działa. Oznacza to, że uruchomiła się automatycznie po restarcie. W przypadku usług, które nie są skonfigurowane do automatycznego uruchamiania, musisz skonfigurować je samodzielnie.
Możemy wyłączyć usługę MySQL i zrestartować system, aby przetestować, czy uruchamia się automatycznie. W systemach Debian i Ubuntu można użyć update-rc.d polecenia, aby dodać lub usunąć usługi z systemu init. Wprowadź następujące polecenie, aby wyłączyć usługę MySQL:
|
1 |
sudo update-rc.d mysql disable |
Zrestartuj system i połącz się ponownie za pomocą SSH. Spróbuj połączyć się z MySQL za pomocą następującego polecenia:
|
1 |
mysql -u root -p |
Otrzymasz błąd MySQL, taki jak:
|
1 |
ERROR 2002 (HY000): Can't connect to local MySQL server |
Następnie wprowadź następujące polecenie, aby ponownie włączyć usługę:
|
1 |
sudo update-rc.d mysql enable |
Jeśli korzystasz z dystrybucji CentOS, polecenie będzie następujące:
|
1 |
sudo chkconfig mysql enable |
Ponieważ MySQL nie uruchamiał się początkowo, musisz go uruchomić. Wprowadź następujące polecenie:
|
1 |
sudo service mysql start |
Step 3: Configure a Service (MySQL) to Auto-start after a System Crash
System V nie uruchomi procesu automatycznie po awarii. Możemy zasymulować awarię systemu, znajdując identyfikator procesu (PID) MySQL i zabijając go. Wprowadź następujące polecenie, aby znaleźć identyfikator procesu MySQL:
|
1 |
ps -ef | grep mysql |
W wyjściu znajdź procesy MySQL. Głównymi procesami uruchamiającymi MySQL są mysqld_safe i mysqld. Zanotuj ich identyfikatory procesów (są to liczby) i użyj następujących poleceń, aby je zabić:
|
1 2 |
sudo kill -9 mysqldsafe_number sudo kill -9 mysqld_number |
Sprawdź status usługi MySQL za pomocą polecenia:
|
1 |
sudo service mysql status |
Wynik wskaże, że MySQL został zatrzymany. Możemy go zrestartować ręcznie za pomocą polecenia service start. Chcemy jednak, aby proces ten odbywał się automatycznie. Aby osiągnąć to automatyczne zachowanie, musimy edytować plik /etc/inittab. Jest to pierwszy plik, który System V init odczytuje podczas uruchamiania. Plik /etc/inittab zawiera instrukcje dotyczące zachowania procesu w przypadku jego awarii. Jeśli jest odpowiednio skonfigurowany, restartuje system ponownie w przypadku awarii. W naszym przypadku chcemy upewnić się, że MySQL jest jedną z tych usług.
Plik /etc/inittab jest niezwykle kluczowy dla dystrybucji Linuksa. Decyduje o tym, czy system się zrestartuje, czy nie. Jeśli popełnisz błąd w poleceniach, system może nie uruchomić się po restarcie. Jak już wspomnieliśmy, mamy nadzieję, że wypróbowujesz te polecenia wyłącznie w środowisku serwera testowego, a nie produkcyjnego.
First, make a copy of the file before you begin editing:
|
1 |
sudo cp /etc/inittab /etc/inittab.original |
Następnie otwórz plik za pomocą nano:
|
1 |
sudo nano /etc/inittab |
Przewiń na koniec pliku i dodaj następujący fragment kodu:
|
1 |
ms:2345:respawn:/bin/sh /usr/bin/mysqld_safe |
Powyższe polecenie restartuje proces mysql_safe po awarii systemu. Składa się z czterech pól oddzielonych dwukropkami, jak wyjaśniono poniżej:
- ms: Określa identyfikator procesu.
- 2345: Określa poziomy uruchamiania (runlevels), do których ma zastosowanie polecenie. W tym przypadku: poziomy uruchamiania 2, 3, 4, 5.
- respawn: Określa akcję. W tym przypadku wznawiamy (respawn) lub restartujemy proces.
- /bin/sh /usr/bin/mysqld_safe: Ostatnia część definiuje proces – polecenie, które jest wykonywane w celu zrestartowania procesu.
Teraz naciśnij Ctrl + O i Enter, aby zapisać plik. Następnie naciśnij Ctrl + X, aby zamknąć edytor. Wprowadź następujące polecenie, aby uruchomić usługę:
|
1 |
sudo service mysql start |
Zrestartuj serwer, a następnie uruchom wyjaśnione wcześniej polecenia, aby znaleźć numer procesu. Następnie zabij procesy, zaczynając od polecenia ps -ef | grep mysql. Odczekaj kilka minut i wprowadź następujące polecenie, aby sprawdzić status MySQL:
|
1 |
sudo service mysql status |
Wynik powinien wskazywać, że usługa MySQL działa, co oznacza, że była w stanie uruchomić się ponownie po awarii. Możesz postępować w ten sam sposób dla innych usług na swoim serwerze.
Automatyczne uruchamianie usług za pomocą Upstart
Upstart to kolejny system init, który został początkowo wprowadzony w Ubuntu 6, a później stał się domyślnym w Ubuntu 9.10. RHEL 6 i jego pochodne oraz Google Chrome OS również używają systemu init Upstart. Aby wykonać kroki opisane w tej sekcji, powinieneś posiadać serwer z jedną z następujących dystrybucji:
- Ubuntu 9.10 do Ubuntu 14.10 oraz wersja LTS systemu Ubuntu, tj. Ubuntu 14.04.
- CentOS 6
Zobaczmy, jak można skonfigurować pliki Upstart, aby automatycznie uruchamiać usługi serwera w przypadku ponownego uruchomienia lub awarii systemu. Upstart używa plików konfiguracyjnych przechowywanych w katalogu /etc/init do kontrolowania usług w dystrybucji Linux. Większość najnowszych wersji aplikacji serwerowych, takich jak MySQL i Nginx, instaluje własne skrypty init w katalogu /etc/init . Dzięki temu uruchomią się one po ponownym uruchomieniu oraz po awarii systemu bez konieczności wykonywania jakichkolwiek działań z Twojej strony.
Lista kontrolna automatycznego uruchamiania dla Upstart
Oto kilka przykładowych konfiguracji, które należy sprawdzić, aby upewnić się, że usługa jest skonfigurowana do automatycznego uruchamiania.
- Upewnij się, że usługa posiada skrypt init w katalogu /etc/init/service_name.conf – service_name będący rzeczywistą nazwą Twojej konkretnej usługi. Powinieneś sprawdzić obecność następujących dwóch linii w pliku /etc/init/service_name.conf:
- Linia zawierająca coś w rodzaju start on runlevel [2345]. Wskazuje ona, że usługa zostanie uruchomiona przy ponownym uruchomieniu systemu.
- Linia zawierająca coś w rodzaju respawn. Wskazuje ona, że usługa zostanie ponownie uruchomiona/zrestartowana po awarii systemu.
- Upewnij się, że w katalogu nie ma pliku nadpisania usługi: /etc/init/service_name.override, chyba że Ty lub inny administrator systemu utworzyliście go wcześniej.
- Wprowadź następujące polecenia, aby zatrzymać i uruchomić usługę:
|
1 2 |
sudo initctl stop service_name sudo initctl start service_name |
- Zrestartuj system i połącz się ponownie po kilku minutach. Teraz przeprowadź testy, aby sprawdzić, czy wszystko działa
- Po ponownym uruchomieniu sprawdź, czy usługa działa. Wprowadź następujące polecenie, aby wyszukać numer procesu, zastępując service_name rzeczywistą nazwą testowanej usługi:
|
1 |
ps -ef | grep service_name |
- Gdy uzyskasz numer procesu, wprowadź następujące polecenie, aby zabić proces:
|
1 |
sudo kill -9 process_number |
- Odczekaj kilka sekund i ponownie sprawdź, czy proces działa.
Praktyczna konfiguracja Upstart z rzeczywistą usługą
W kolejnej sekcji postaramy się zademonstrować, jak można użyć Upstart z rzeczywistą usługą. Testy przeprowadzimy na serwerze z maszyną wirtualną Ubuntu 14.04 z MySQL jako usługą. Połącz się ze swoim serwerem testowym Ubuntu 14.04 za pomocą ssh lub putty, jeśli korzystasz z systemu Windows. Standardowo powinieneś używać użytkownika niebędącego administratorem (non-root) z uprawnieniami sudo. Po zalogowaniu możemy rozpocząć kroki:
Krok 1: Instalacja MySQL
Zawsze pamiętaj o zaktualizowaniu pakietów przed zainstalowaniem nowego oprogramowania:
|
1 |
sudo apt-get update |
Teraz wprowadź następujące polecenie, aby zainstalować serwer MySQL:
|
1 |
sudo apt-get install mysql-server –y |
Po wyświetleniu monitu utwórz hasło roota. Poczekaj na zakończenie instalacji i uruchom następujące polecenie, aby rozpocząć zabezpieczanie instalacji MySQL:
|
1 |
mysql_secure_installation |
Postępuj zgodnie z monitami, tak jak w poprzedniej sekcji. Następnie przeładuj uprawnienia (flush privileges), aby zmiany weszły w życie natychmiast.
Krok 2: Konfiguracja usługi (MySQL) do automatycznego uruchamiania po restarcie systemu
MySQL jest skonfigurowany tak, aby uruchamiał się automatycznie po restarcie. Przyglądamy się jego plikom konfiguracyjnym tylko po to, aby dowiedzieć się, jak możemy skonfigurować nasze własne aplikacje, aby również uruchamiały się automatycznie po restarcie. Usługa MySQL została uruchomiona automatycznie po instalacji. Potwierdźmy jednak, że działa, wpisując następujące polecenie:
|
1 |
sudo initctl status mysql |
Powinieneś zobaczyć dane wyjściowe wskazujące, że usługa MySQL działa, coś w stylu:
|
1 |
mysql start/running, process 2553 |
Zrestartuj serwer i zaloguj się ponownie. Ponownie wpisz następujące polecenie, aby sprawdzić, czy działa:
|
1 |
sudo initctl status mysql |
Wynik wskaże, że MySQL działa, co oznacza, że został automatycznie uruchomiony po restarcie. W tym przypadku nic nie trzeba zmieniać. Jednak to zachowanie może być inne dla innych aplikacji. Możesz się zastanawiać, skąd system inicjalizacji Upstart wie, że powinien automatycznie uruchomić MySQL po restarcie. MySQL instaluje swój plik konfiguracyjny startowy Upstart w lokalizacji /etc/init/mysql.conf. Pliki Upstart nie są skryptami powłoki, ale plikami tekstowymi z blokami skryptów dla zdarzeń pre-start i post-start. Bloki te instruują system Upstart, co ma wykonać, gdy proces MySQLd się uruchamia lub gdy już się uruchomił.
Wpisz następujące polecenie, aby otworzyć plik w edytorze nano:
|
1 |
sudo nano /etc/init/mysql.conf |
Zawartość pliku może wyglądać następująco:
|
1 2 3 4 5 6 7 8 |
description "MySQL Server" author "Mario Limonciello <superm1@ubuntu.com>" start on runlevel [2345] stop on starting rc RUNLEVEL=[016] respawn respawn limit 2 5 |
Jak widać, blok start instruuje MySQL, aby uruchamiał się na poziomach uruchomienia 2, 3, 4, 5, a nie 0, 1, 6. Jeśli definiujesz konfigurację Upstart dla swojej aplikacji, zdefiniujesz ją w tej sekcji. Blok respawn instruuje Upstart, co ma zrobić po awarii. Omówimy to w następnej sekcji, więc pozostaw plik otwarty w edytorze nano.
Krok 3: Konfiguracja usługi (MySQL) do automatycznego uruchamiania po awarii
Dyrektywa respawn w pliku /etc/init/mysql.conf instruuje Upstart, aby zrestartował usługę MySQL po awarii.
Dyrektywa respawn limit instruuje Upstart, ile razy powinien spróbować zrestartować uszkodzoną usługę MySQL w przedziale czasu określonym w sekundach. Pierwszy argument (2) wskazuje liczbę prób. Drugi argument (5) wskazuje interwał w sekundach. Jeśli po awarii Upstart nie zdoła ponownie uruchomić usługi MySQL w określonym limicie, pozostanie ona zatrzymana. Takie zachowanie ma na celu ochronę stabilności systemu w przypadku, gdyby próbował on w nieskończoność restartować stale ulegające awarii usługi. Możesz teraz zamknąć edytor bez wprowadzania żadnych zmian.
Przetestujmy, czy MySQL podniesie się automatycznie po awarii. Wpisz następujące polecenie, aby sprawdzić status i uzyskać numer procesu usługi MySQL:
|
1 |
sudo initctl status mysql |
Wynik powinien wyglądać mniej więcej tak. Zanotuj numer procesu, ponieważ użyjemy go później:
|
1 |
mysql start/running, process 738 |
Następnie wpisz następujące polecenie, aby zabić proces. Emuluje to awarię. Zastąp numerem procesu, który otrzymałeś w poprzednim poleceniu:
|
1 |
sudo kill -9 7738 |
Ponownie sprawdź status MySQL, wpisując następujące polecenie:
|
1 |
sudo initctl status mysql |
Powinien działać ponownie, ale prawdopodobnie z innym numerem procesu:
|
1 |
mysql start/running, process 1428 |
Dzieje się tak z powodu dyrektywy respawn w /etc/init/mysql.conf pliku. Zapewnia on, że w przypadku jakiejkolwiek awarii systemu MySQL uruchomi się automatycznie. Dzięki temu Twoja aplikacja zależna od bazy danych MySQL będzie nadal działać zgodnie z oczekiwaniami.
Automatyczne uruchamianie usług za pomocą Systemd
Systemd to system inicjalizacji znajdujący się w większości najnowszych dystrybucji Linuksa. Prawdopodobnie to jego użyjesz, gdy uruchomisz nowy VPS. Po raz pierwszy został wprowadzony w Fedora. Jest dostarczany z RHEL 7 i jego pochodnymi, takimi jak CentOS 7. Od wersji Ubuntu 15.04 Systemd jest dostępny natywnie. Systemd jest wstecznie kompatybilny ze skryptami inicjującymi i poleceniami System V. W związku z tym każda usługa System V powinna działać pod kontrolą Systemd. Większość poleceń używanych w System V i Upstart została zmodyfikowana do działania z Systemd.
Dzięki Systemd większość aplikacji serwerowych, takich jak MySQL i Nginx, uruchomi się automatycznie po ponownym uruchomieniu lub wyłączeniu systemu, bez konieczności wprowadzania jakichkolwiek zmian. W przypadku własnych aplikacji należy utworzyć własne skrypty inicjujące, aby automatycznie restartować usługi.
Więcej szczegółowych informacji na temat Systemd znajdziesz w naszym poradniku dotyczącym zarządzania usługami i jednostkami Systemd za pomocą Systemctl.
Lista kontrolna automatycznego uruchamiania dla Systemd
Oto kilka przykładowych konfiguracji, które należy sprawdzić, aby upewnić się, że usługa jest skonfigurowana do automatycznego uruchamiania z Systemd.
- Usługa musi posiadać działający skrypt inicjujący Systemd zlokalizowany w /etc/systemd/system/multi-user.target.wants/serviceName.service. ServiceName to rzeczywista nazwa konfigurowanej usługi.
- Polecenie włączające usługę to:
|
1 |
sudo systemctl enable serviceName.service |
- Polecenie to tworzy dowiązanie symboliczne w katalogu /etc/systemd/system/multi-user.target.wants/ , które może wyglądać podobnie do:
|
1 |
lrwxrwxrwx 1 root root 11 Dec 1 04:43 /etc/systemd/system/multi-user.target.wants/serviceName.service -> /usr/lib/systemd/system/serviceName.service |
- Po utworzeniu tego dowiązania symbolicznego automatyczne ponowne uruchamianie po rozruchu zostanie włączone.
- Aby aktywować zmiany, przeładuj demona systemowego, a następnie przeładuj usługę za pomocą następujących poleceń:
|
1 2 3 |
sudo systemctl daemon-reload sudo systemctl restart serviceName.service |
- Aby przetestować, czy konfiguracja uruchomi usługę po ponownym uruchomieniu, możesz zrestartować system:
|
1 |
sudo reboot |
- Po ponownym uruchomieniu systemu wyszukaj numer procesu za pomocą polecenia:
|
1 |
ps -ef | grep serviceName |
- Zanotuj numer procesu i zabij go za pomocą polecenia:
|
1 |
sudo kill -9 process_number |
- Odczekaj kilka sekund i ponownie wyszukaj usługę, aby zweryfikować, czy została ponownie uruchomiona.
Praktyczna konfiguracja Systemd na przykładzie rzeczywistej usługi
W tej sekcji spróbujemy skonfigurować usługę MySQL na maszynie wirtualnej z systemem Ubuntu 20.04.
Krok 1: Połącz się ze swoim wirtualnym serwerem prywatnym (Ubuntu 20.04 lub CentOS 7 x64)
Zaloguj się na swój VPS lub utwórz go w panelu Cloudsigma i połącz się za pomocą ssh lub putty, jeśli korzystasz z systemu Windows. W tej części poradnika używamy serwera Ubuntu 20.04. Te same polecenia mogą mieć zastosowanie do CentOS 7. Upewnij się, że używasz użytkownika innego niż root z uprawnieniami sudo.
Krok 2: Zainstaluj MySQL (usługę, którą konfigurujemy)
Najpierw zaktualizuj system:
|
1 |
sudo apt update |
Następnie możesz zainstalować serwer MySQL za pomocą polecenia:
|
1 |
sudo apt install mysql-server –y |
Następnie uruchom następujące polecenie, aby rozpocząć zabezpieczanie MySQL:
|
1 |
sudo mysql_secure_installation |
Skrypt zapyta, czy chcesz skonfigurować komponent VALIDATE PASSWORD, czy nacisnąć dowolny klawisz, aby kontynuować bez włączania tego komponentu. Skorzystaj z tego linku, aby dowiedzieć się więcej o komponencie walidacji haseł MySQL.
Naciśnij 1, aby to włączyć, a następnie wybierz średni poziom, naciskając 1. Wprowadź silne hasło: kombinację wielkich i małych liter, znaków specjalnych oraz cyfr. Potwierdź hasło i potwierdź monit z pytaniem, czy chcesz użyć wprowadzonego hasła jako hasła roota. W przypadku pozostałych monitów naciśnij y, aby je zaakceptować, tak jak w poprzednich sekcjach. Na koniec opróżnij uprawnienia (flush privileges) dla MySQL, aby przeładować zmiany.
Krok 3: Konfiguracja automatycznego uruchamiania MySQL po restarcie
MySQL jest skonfigurowany tak, aby uruchamiał się po restarcie, więc nie musisz wprowadzać żadnych zmian. Możemy jednak użyć plików konfiguracyjnych MySQL, aby dowiedzieć się, jak konfigurować własne pliki.
Najpierw sprawdź, czy usługa MySQL została skonfigurowana do uruchamiania podczas startu systemu. Wprowadź następujące polecenie (pamiętaj, że w systemie CentOS usługa MySQL nazywa się mysqld):
|
1 |
sudo systemctl is-enabled mysql.service |
Oto wynik:

Następnie zrestartuj serwer VPS, wprowadzając następujące polecenie:
|
1 |
sudo reboot |
Połącz się ponownie przez SSH i wprowadź następujące polecenie, aby sprawdzić status usługi MySQL:
|
1 |
sudo systemctl status mysql.service |
Powinieneś otrzymać wynik podobny do tego na poniższym zrzucie ekranu:

Aby wyłączyć usługę MySQL, wprowadź następujące polecenie:
|
1 |
sudo systemctl disable mysql.service |
Wynik wskazuje, że dowiązania symboliczne (symlinki) do usługi MySQL zostały usunięte z Systemd:

Możesz przetestować, czy usługa jest włączona w systemie inicjalizacji Systemd, wprowadzając następujące polecenie:
|
1 |
sudo systemctl is-enabled mysql.service |
Wynik pokaże, że jest wyłączona. Jeśli zrestartujesz system, MySQL nie uruchomi się podczas startu:
![]()
Włącz usługę, wprowadzając następujące polecenie:
|
1 |
sudo systemctl enable mysql.service |
Wynik pokazuje dowiązanie symboliczne do usługi MySQL utworzone w systemie inicjalizacji Systemd:

Po restarcie usługa MySQL uruchomi się automatycznie.
Krok 4: Konfiguracja automatycznego uruchamiania MySQL po awarii
MySQL jest skonfigurowany tak, aby restartował się automatycznie po awarii. Przyjrzyjmy się, jak ta konfiguracja jest zaimplementowana w Systemd. Systemd używa plików jednostek (unit files) do konfiguracji. Wprowadź następujące polecenie, aby otworzyć plik konfiguracyjny mysql.service w edytorze nano:
|
1 |
sudo nano /etc/systemd/system/multi-user.target.wants/mysql.service |
Wynik wygląda następująco:

Interesuje nas dyrektywa Restart . Zgodnie z definicją, MySQL zrestartuje się w przypadku awarii. Dyrektywa Restart definiuje, co powinno się wydarzyć w Systemd, podobnie jak dyrektywa Respawn w Upstart.
Nie wszystkie usługi będą miały tę dyrektywę. Aby umożliwić usłudze restart po awarii, zawsze możesz dodać dyrektywę Restart pod sekcją [Service] pliku konfiguracyjnego jednostki usługi. Jeśli nagłówek [Service] nie istnieje, dodaj go. Teraz wyjdź z edytora, naciskając Ctrl + X.
Aby zasymulować awarię, znajdź identyfikator procesu (PID) MySQL, wprowadzając następujące polecenie:
|
1 |
sudo systemctl status mysql.service |
Polecenie sprawdzania statusu wyświetla identyfikator procesu, w naszym przypadku jest to 3555:

Wprowadź następujące polecenie, aby zabić proces. Zastąp go identyfikatorem procesu, który otrzymałeś na swoim serwerze:
|
1 |
sudo kill -9 3555 |
Wprowadź następujące polecenie, aby sprawdzić status:
|
1 |
sudo systemctl status mysql.service |
Wynik pokazuje, że MySQL działa, ale z nowym identyfikatorem procesu. Oznacza to, że został automatycznie zrestartowany po awarii:

Podsumowanie
W tym samouczku przedstawiliśmy trzy systemy inicjalizacji w dystrybucjach Linuksa: System V, Upstart i Systemd. Dowiedzieliśmy się, jak używać dowolnego z tych systemów inicjalizacji do konfiguracji stale działających usług, aby uruchamiały się automatycznie po restarcie lub awarii systemu. Powinno to służyć jako punkt wyjścia, gdy zajdzie potrzeba skonfigurowania własnych usług. Część pierwsza tej serii była głównie praktycznym samouczkiem. druga część jest bardziej teoretyczna i zawiera więcej szczegółów na temat tego, co robiliśmy w części pierwszej. Nie usuwaj jeszcze swoich serwerów testowych, ponieważ będziesz z nich korzystać również w części drugiej.
Miłego korzystania z komputera!
Komentarze
Brak komentarzy. Bądź pierwszy.