Hogyan konfiguráljunk egy Linux szolgáltatást az automatikus elindulásra újraindítás vagy rendszerösszeomlás után: 2. rész (Elméleti magyarázatok)

A kétrészes útmutató második részében, amely a Linux-szolgáltatások újraindítás vagy rendszerösszeomlás utáni automatikus elindulásának beállításáról szól, részletesen tárgyaljuk az init rendszert. Hivatkozhat a A sorozat 1. része: Hogyan konfiguráljunk egy Linux szolgáltatást az automatikus indulásra újraindítás vagy rendszerösszeomlás után: Gyakorlati példák itt.

A jelenlegi útmutató erősen elméleti jellegű lesz. Ezért érdemes referenciaként használnia, hogy mélyebb megértést szerezzen az init rendszer működéséről Linux alatt. Az útmutató első részében megosztottunk néhány kódrészletet és indító parancsfájlt, amelyeket az init rendszer olvas be az induláskor. Példaként használtuk a MySQL-t is, hogy megtanuljuk, hogyan engedélyezhető és tiltható le egy Linux szolgáltatás automatikus elindulása összeomlás vagy újraindítás után. Ahogy a kétrészes útmutató első részében megtanulta, a Linux különböző disztribúcióiban három init rendszert használnak: a System V-öt, az Upstartot és a Systemd-t. Hivatkozhat az útmutató első részére, hogy megértse, melyik disztribúció és verzió van beállítva egy adott init rendszer használatára.

Ebben az útmutatóban elmagyarázzuk az útmutató első részében használt kódot. Részletesen bemutatjuk azokat a parancsokat és konfigurációs fájlokat, amelyeket az init rendszer használ. Kezdjük el!

Előfeltételek

A kétrészes útmutató első részének lezárásában említettük, hogy érdemes futva hagyni a három tesztszervert. Ha törölte őket, visszaléphet és újra létrehozhatja őket. Ez segíteni fog az útmutató követésében. A következő három tesztszerverrel kell rendelkeznie:

• Ubuntu 9.04 és korábbi, vagy Debian 6 x64 (ezt a System V init rendszer bemutatására fogjuk használni)
• Ubuntu 14.04 x64 (ezt az Upstart bemutatására fogjuk használni). Itt egy útmutató arról, hogyan állíthatja be egyszerűen az Ubuntu szerverét.
• CentOS 7 x64 (ezt a Systemd bemutatására fogjuk használni).

Minden olyan szerveren rendelkeznie kell egy sudo jogosultságokkal rendelkező felhasználóval, amelyet a parancsok futtatására fog használni. Ez a Linux sudoers fájl konfigurálásáról szóló útmutató segítséget nyújthat Önnek.

Megjegyzés: Az útmutatóban szereplő parancsok befolyásolják a rendszerszolgáltatásokat. Ezért ne alkalmazza őket éles termelési (production) szerveren.

Futási szintek

A futási szint egy olyan működési szint, amely leírja a Linux rendszer aktuális állapotát az elérhető szolgáltatások tekintetében. A koncepció a System V initből származik. Amikor a Linux rendszer elindul, inicializálja a kernelt, belép egy futási szintre, és lefuttatja az adott futási szinthez kapcsolódó indító parancsfájlt. Indításkor csak egy futási szintet hajthat végre.

A futási szintek egyéb példái közé tartozik a leállítási állapot, az újraindítási mód, az egyfelhasználós mód stb. Minden szint meghatározza, hogy milyen szolgáltatások fussanak az adott állapotban. Egyes szolgáltatások több szinten is futhatnak, míg mások nem.

Hét futási szint létezik: 0-tól 6-ig. Alább látható a hét futási szint meghatározása:

• 0. futási szint: Rendszerleállítás
• 1. futási szint: Egyfelhasználós és mentési mód
• 2., 3., 4. futási szint: Többfelhasználós és szöveges mód engedélyezett hálózattal
• 5. futási szint: Többfelhasználós, hálózatképes és grafikus mód
• 6. futási szint: Rendszer-újraindítás

A futási szintek nem feltétlenül egymás után hajtódnak végre. A 2., 3. és 4. futási szint a futtatott Linux disztribúciótól függően változik. A 4. futási szintet egyes disztribúciókban implementálhatja, másokban nem. Amikor engedélyezte egy szolgáltatás automatikus elindulását – amint azt az első részben kifejtettük –, valójában hozzáadta azt egy futási szinthez. A System V-ben az operációs rendszer egy adott futási szinttel indul, és az indítás során megpróbálja elindítani az adott futási szinthez kapcsolódó összes szolgáltatást. A futási szintek a Systemd-ben célok (targets), amelyeket a Systemd szakaszban fogunk tárgyalni.

Init és PID 1

Az init rendszer a legelső folyamat, amely elindul, amikor a Linux rendszer feláll, és a kernel betöltődik a memóriába. Különböző feladatokat lát el, beleértve annak meghatározását, hogy a felhasználói folyamatok vagy rendszerszolgáltatások hogyan, milyen sorrendben töltődjenek be, és hogy automatikusan elinduljanak-e. Minden Linux disztribúcióban minden folyamatot egy folyamatazonosító (PID) azonosít, és az init PID-je 1. Ez a szülője az összes többi folyamatnak, amelyek a rendszer indulásakor egymás után elindulnak.

Az init története

A legújabb Linux disztribúciókban található init rendszer az eredeti továbbfejlesztése. A Linux disztribúciók legkorábbi verziói a System V init-et használták, amelyet hasonlóan alkalmaztak a Unix rendszerekben is. Ahogy a Linux fejlődött, bevezetésre került az Upstart init démon – ezt az Ubuntu fejlesztette ki. Most (ezen útmutató írásakor, 2021-ben) a Systemd init démonnal rendelkezünk – ezt először a Fedora vezette be. Ahogy a Linux rendszerek tovább fejlődnek, megjelenhet egy újabb init rendszer is. Ebben az útmutatóban ezt a hármat fogjuk tárgyalni: System V, Upstart és Systemd.

Az újabb Linux verziók alapértelmezetten a Systemd init rendszerrel érkeznek. Azonban a visszafelé való kompatibilitás érdekében megtartották a többi, régebbi init rendszert is. A System V-nek különböző megvalósításai léteznek, amelyeket a Linux más változataiban is használhat. Például a FreeBSD, a UNIX egyik változata, a BSD init-et használja. A Debian régebbi verziói a SysVinit-et használják. Mindkettő a System V-ből származik.

Az init démon egyes verziói eltérő módon kezelik a szolgáltatásokat. Az egyes verziókhoz hozzáadott fejlesztések egy olyan robusztus szolgáltatáskezelő eszköz létrehozására irányultak, amely mindent kezel, amire egy Linux rendszernek szüksége van a szolgáltatásoktól, eszközöktől, portoktól kezdve a többi erőforrásig. Szükség volt egy olyan hatékony rendszerre, amely képes az erőforrásokat párhuzamosan betölteni, és amely elegánsan képes felépülni egy rendszerösszeomlásból.

System V indítási sorrend

A System V egy inittab fájlt használ az inicializálási utasítások tárolására. Az Upstart megtartja az inittab fájlt a visszafelé való kompatibilitás érdekében. Íme a System V indítási folyamata:

• Az init rendszer a /sbin/init.
• bináris fájlból származik. Miután az init rendszer betöltődik a memóriába, beolvassa az első fájlját a /etc/inittab.
• helyen. A fájl egyik bejegyzése határozza meg azt a futási szintet, amelyben a gépnek el kell indulnia. Például, ha a futási szint értéke 5-ként van megadva, a Linux többfelhasználós, grafikus módban fog elindulni, engedélyezett hálózattal (ez gyakori az asztali használatra tervezett disztribúciókban). Az itt megadott futási szintet alapértelmezett futási szintként ismerjük, mivel mindig ezt fogja használni a rendszer.
• Ezután az init rendszer tovább keres a /etc/inittab fájlban, és beolvassa, hogy milyen init szkripteket kell futtatnia az adott futási szinthez.

Azáltal, hogy megtalálja, mely szkripteket kell futtatnia egy adott futási szinthez, az init rendszer meghatározza, hogy mely szolgáltatásokat kell elindítania. Általában ezekben az init szkriptekben konfigurálhatja az egyes szolgáltatások indítási viselkedését, ugyanúgy, ahogyan a MySQL szolgáltatást konfiguráltuk az útmutató első részében.

A System V Init szkriptek szerkezete

Ebben a szakaszban részletesen megvizsgáljuk az init szkripteket. A System V konfigurációs fájlok vagy init szkriptek vezérlik a szolgáltatásokat. Az init szkriptek inicializálják a szolgáltatást, innen ered az init szkript elnevezés.

Minden szolgáltatásnak megvan a saját init szkriptje. Például a MySQL init szkript vezérli a MySQL szervert. Az alkalmazások fejlesztői biztosítják az init szkripteket a saját alkalmazásukhoz, míg a natív Linux szolgáltatások az operációs rendszer telepítésével együtt érkeznek. Ha egyedi alkalmazást hoz létre, ahhoz saját, egyedi init szkripteket is készíthet.

Egy szolgáltatás, például a MySQL szerver elindításához a bináris programja először betöltődik a memóriába. A konfigurációjától függően a program továbbra is futhat a háttérben, hogy fogadja az ügyfélkapcsolatokat. A szolgáltatás init szkriptje kezeli a bináris alkalmazás elindítását, leállítását vagy újratöltését. A System V init szkriptejei shell szkriptek. Másik nevük rc (run command) szkriptek.

System V könyvtárszerkezet

Az init szkriptek szülőkönyvtára az /etc könyvtár. A /etc/init.d könyvtár a tényleges könyvtára az init shell szkripteknek. A szkriptek szimbolikus linkkel (symlink) kapcsolódnak az rc könyvtárakhoz.

Több rc könyvtár is található az /etc könyvtárban, mindegyik nevében egy számmal. A számok a különböző futási szinteket képviselik. Ha kilistázza a könyvtár tartalmát, olyan neveket fog látni, mint a /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, stb.

Ha megnézi az egyes rc könyvtárak tartalmát, olyan fájlokat fog látni, amelyek kezdőbetűje K vagy S a fájlnevükben, amit két számjegy követ. Ezek a fájlok szimbolikus linkeket tartalmaznak, amelyek a tényleges program valódi init shell parancsfájljaira mutatnak vissza. A K és S betűk rövidítések: a K jelentése Kill vagy Stop, míg az S jelentése Start. A fájlnevekben szereplő két számjegy a végrehajtási sorrendet jelöli. Ha egy K05script_name nevű fájlt lát, az egy K09script_name.

Rendszerindítás

Haladva az indítási folyamattal, lássuk, hogyan hívódnak meg az init parancsfájlok.

Az S és K parancsfájlokat nem közvetlenül az init rendszer hívja meg. Ehelyett egy másik parancsfájl hívja meg őket: az /etc/init.d/rc parancsfájl. Az /etc/inittab fájl utasítja az init démont, hogy a rendszernek alapértelmezés szerint melyik futási szinten (runlevel) kell elindulnia. A megadott futási szinttől függően az /etc/inittab fájl egyik sora meghívja az /etc/init.d/rc parancsfájlt, paraméterként átadva az alapértelmezett futási szintet. Ezt a paramétert használva a parancsfájl meghívja a megfelelő /etc/rcN.d könyvtárban található fájlokat, ahol az N a futási szintet jelöli. Például, ha a szerver az 5-ös futási szinttel indul, a megfelelő fájlok az /etc/rc5.d könyvtárban lesznek meghívva.

Az rc könyvtáron belül az összes K parancsfájl számszerű sorrendben fut le a következő argumentummal: stop, míg az összes S parancsfájl hasonlóan fut le a start argumentummal. A program azon tényleges init shell parancsfájljai, amelyekre az /etc/rcN.d alatti szimbolikus linkek mutatnak, rendre a stop és start paraméterekkel lesznek meghívva.

Egyszerűen fogalmazva, amikor egy Linux rendszer belép egy bizonyos futási szintre vagy átvált arra, bizonyos parancsfájlok futnak le egyes szolgáltatások leállítására, míg mások más szolgáltatások elindítására. Ez a folyamat biztosítja, hogy minden olyan folyamat leálljon, amelynek nem kellene futnia egy adott Linux állapotban, és minden olyan folyamat automatikusan elinduljon, amelynek futnia kell.

System V automatikus indítás

Amikor engedélyezi egy szolgáltatás automatikus indítását a rendszerindításkor, közvetlenül módosítja az init viselkedését. Például, ha beállít egy szolgáltatást, hogy automatikusan induljon a 2-es futási szinten, az init folyamat létrehozza a megfelelő szimbolikus linkeket az /etc/rc2.d könyvtárban. A megértés megkönnyítése érdekében ezt egy példával magyarázzuk el.

System V példa

Hogy gyakorlati példát mutassunk, az 1. részben szereplő MySQL szolgáltatáskonfigurációt fogjuk használni. Jelentkezzen be a Debian 6 VPS-re a sudo/root felhasználójával ssh-n keresztül (vagy putty-val, ha Windowst használ), és kövesse az alábbi lépéseket.

1. lépés: Az inittab fájl megnyitása és vizsgálata

Először írja be a következő parancsot az inittab fájl tartalmának megtekintéséhez a terminálon:

A fájl tartalmának valahogy így kell kinéznie:

A 2-es szám azt a futási szintet jelöli, amellyel a rendszer elindul. Ebben az esetben a 2-es futási szint az alapértelmezett, így ez a Debian rendszer a 2-es futási szinten fog elindulni többfelhasználós, szöveges módban. A megerősítéshez futtathatja a következő parancsot:

A kimenet a következőhöz hasonló lesz:

2. lépés: Az rc könyvtárak vizsgálata

Ezután az rc könyvtárak listázásához futtassa a következő parancsot:

Itt látható egy képernyőkép a kimenetről:

Ahogy korábban az inittab fájlban láttuk, a rendszer úgy van konfigurálva, hogy a következő futási szinten induljon: runlevel 2, ezért az /etc/rc2.d alatti parancsfájlok fognak lefutni a rendszer indításakor. A könyvtár tartalmát a következő paranccsal listázhatja ki:

Ahogy a kimenetből látható, a fájlok csupán szimbolikus linkek, amelyek a tényleges parancsfájlokra mutatnak a következő könyvtárban: /etc/init.d. Itt látható egy részlet a kimenetből:

Ebben a könyvtárban nincsenek K parancsfájlok, csak S (start) parancsfájlok. A parancsfájlok elindítják az itt linkelt szolgáltatásokat, mint például az rsync. Észreveheti a listában szereplő mysql szolgáltatást is, amelyet a következő alfejezetben tárgyalunk.

3. lépés: Az Init parancsfájl vizsgálata

Ha egy System V-kompatibilis szolgáltatás telepítésre kerül, az létrehoz egy shell scriptet az /etc/init.d könyvtárban. A MySQL shell script elérhetőségét a következő parancs beírásával ellenőrizheti:

Az alábbi kimenetet mutatja:

A fájl meglehetősen nagy. A tartalmának megtekintéséhez írja be a következő parancsot:

4. lépés: A chkconfig vagy a sysv-rc-conf használata

Chkconfig egy olyan parancs, amelyet az RHEL-alapú disztribúciókban, például a CentOS használhat a System V-kompatibilis szolgáltatások engedélyezésére vagy letiltására. Arra is használhatja, hogy listázza a telepített szolgáltatásokat és a hozzájuk tartozó futási szinteket. Íme az ehhez szükséges parancs (CentOS-en működik):

A Debian disztribúciókban egy ilyen segédprogram natívan nem létezik. Az update-rc.d a Debian rendszerekben csak telepíti és eltávolítja a szolgáltatásokat a futási szintekről. Elérhető egy egyéni eszköz, amellyel a chkconfig funkciót átültetheti a Debian rendszerekbe. Telepítéséhez írja be a következő parancsot:

A telepítés után a következő parancs futtatásával megtekintheti a különböző szolgáltatások futási szintű viselkedését:

Ennek a parancsnak a kimenete egy táblázatba van formázva, amely a bal oldalon a szolgáltatás nevét, a jobb oldalon pedig azt a futási szintet mutatja, amely alatt a szolgáltatás fut:

Az X jelzi azt a futási szintet, amely alatt a szolgáltatás futni fog. Ez az eszköz lehetővé teszi egy szolgáltatás letiltását vagy engedélyezését egy adott futási szinthez a nyílbillentyűk és a szóköz segítségével. Az eszközből való kilépéshez nyomja meg a Q billentyűt.

5. lépés: A MySQL indítási viselkedésének tesztelése a rendszerindítás során

A fenti képernyőképen látható, hogy a mysql szolgáltatás engedélyezve van a 2,3,4,5 futási szinteken. A MySQL-t a következő paranccsal tilthatja le:

A kimenet így néz ki. Vegye figyelembe, hogy a szolgáltatás minden futási szinten leállt:

Futtassa az alábbi parancsot a könyvtár tartalmának megtekintéséhez:

Lásd a mysql sort az alábbi kimenetben:

A kimenet azt mutatja, hogy a szimbolikus link K-ra változott, ami a Kill (leállítás) rövidítése. Ezért a MySQL alapértelmezés szerint nem fog automatikusan elindulni a 2-es futási szinten. Amikor engedélyez vagy letilt egy szolgáltatást a System V-ben, ez történik. Mindaddig, amíg létezik egy S (start) script a szolgáltatás alapértelmezett futási szintű könyvtárában, az init démon elindítja azt a szolgáltatást a rendszerindítás során.

A szolgáltatás újbóli engedélyezéséhez írja be a következő parancsot:

6. lépés: A MySQL indítási viselkedésének tesztelése rendszerösszeomlás után

Ebben a szakaszban azt tárgyaljuk, hogyan kezeli a System V a szolgáltatások összeomlását. Ezt a tudást felhasználhatja egyéni szolgáltatásai összeomlás utáni viselkedésének konfigurálására.

Az útmutató első részében módosítottuk az /etc/inittab fájlt, hogy a MySQL automatikusan elinduljon egy összeomlás után. A következő sort adtuk hozzá ennek a viselkedésnek az engedélyezéséhez:

Ezt a viselkedést néhány teszttel ellenőrizhetjük. Először indítsa újra a VPS-t a következő parancs beírásával:

Az újraindítás után ellenőrizze, hogy a mysql_safe és a mysqld milyen folyamatazonosítókkal futnak. A folyamatazonosítók lekéréséhez írja be a következő parancsot:

Az alábbi kimenetet kaptuk:

Jegyezze meg a folyamatazonosítókat. A mi esetünkben ez az 1836 és a 186338 volt. Most szimuláljon egy összeomlást a folyamat leállításával a -9 kapcsoló segítségével, a következő parancs beírásával. Ne felejtse el behelyettesíteni a saját folyamatazonosítóit:

Néhány perc elteltével ellenőrizze a MySQL állapotát a következő parancs futtatásával:

A kimenet azt mutatja, hogy a MySQL fut, ami azt jelenti, hogy a szimulált összeomlás után újraindult. Ha újra futtatja a ps -ef | grep mysql parancsot, látni fogja, hogy mind a mysqld_safe mind a mysqld folyamatok futnak, bár új azonosítókkal.

Megpróbálhatja többször is leállítani a folyamatokat, és néhány perc múlva újraindulnak. Ez a viselkedés annak a sornak köszönhető, amelyet a /etc/inittab fájlhoz adtunk hozzá. Így konfigurálhatja a szolgáltatásokat az automatikus újraindulásra összeomlás után a System V-ben. A szintaxis megtekintéséhez olvassa el újra a bemutató 1. részét.

Néhány egyedi szolgáltatás tartalmazhat hibákat, és több kísérlet után sem indul újra. Az init démon megpróbálja újraindítani a szolgáltatást, de ha ez két percen belül több mint tízszer meghiúsul, a Linux rendszer legfeljebb 5 percre letiltja a szolgáltatást. Ez segít stabilan tartani a rendszert, és biztosítja, hogy a rendszererőforrások ne pazarolódjanak az összeomló szolgáltatásokra. Érdemes ellenőrizni a rendszernaplókat az egyedi alkalmazások javítandó problémáinak azonosítása érdekében.

Az Upstart bemutatása

A System V init rendszer hosszú ideig kulcsfontosságú volt a Linux disztribúciók számára. Azonban, ahogy az a technológiánál lenni szokott, ez is folyamatosan fejlődik. A Linux ökoszisztéma óriásit nőtt a nyílt forráskódú közösség támogatásának köszönhetően. A System V soros módon tölti be a feladatokat és szolgáltatásokat, ami bonyolultságot okoz és időt vesz igénybe. Emellett a modern, menet közben csatlakoztatható adathordozók megjelenése, amelyekre a System V-öt nem tervezték, szükségessé tette egy másik init rendszer kifejlesztését.

Az Ubuntu fejlesztői elkezdtek dolgozni egy másik inicializációs rendszeren. Ezt az init rendszert úgy tervezték, hogy kezelje az operációs rendszer gyorsabb betöltését, biztosítsa az összeomlott szolgáltatások tiszta leállítását, kiszámíthatóan tartsa a rendszerszolgáltatások közötti függőségeket, és kezelje a menet közben csatlakoztatható adathordozókat. Így született meg az Upstart démon.

Az Upstart init több szempontból is előnyösebb a System V inithez képest:

• Az Upstart nem sorosan tölti be a szolgáltatásokat, mint a System V, így csökkenti a rendszer rendszerindítási idejét.
• Úgy tervezték, hogy jobban kezelje az összeomlott szolgáltatásokat a tiszta leállítással és a szolgáltatások újraindításával.
• Az Upstart rugalmas eseményrendszert használ a szolgáltatások kezelésének testreszabásához a különböző állapotokban.
• Az init elkerüli a szolgáltatások betöltésére és kezelésére szolgáló bonyolult shell scripteket, mint amilyenek a System V-ben vannak. Az Upstart egyszerű, könnyen érthető és módosítható konfigurációs fájlokat használ.
• Az Upstart a visszafelé való kompatibilitás figyelembevételével készült. Az /etc/init.d/rc script továbbra is fut a natív System V szolgáltatások kezelésére.
• Elkerüli a felesleges szimbolikus linkek fenntartását, amelyek mind ugyanarra a scriptre mutatnak.

Upstart események

Az Upstart eseményalapú, ami lehetővé teszi, hogy több eseményt társítsunk ugyanahhoz a szolgáltatáshoz. Ez az eseményalapú architektúra rugalmas szolgáltatáskezelést biztosít. Minden esemény meghívhat egy kifejezetten az adott eseményre vonatkozó shell scriptet.

Az Upstart események közé tartoznak:

• Starting
• Started
• Stopping
• Stopped

Egy esemény közben a szolgáltatás különböző állapotokban lehet, többek között:

• Waiting
• Pre-start
• Starting
• Post-start
• Running
• Pre-stop
• Stopping
• Post-stop

Az Upstart init konfigurálható úgy, hogy mindegyik állapothoz műveleteket rendeljen, innen ered a rugalmas kialakítása.

Az Upstart Init indítási sorrendje

Az Upstart init futtatja a /etc/init.d/rc scriptet indításkor, csakúgy, mint a System V. Ez a script normál módon futtatja a System V init scripteket a visszafelé való kompatibilitás biztosítása érdekében.

Az Upstart konfigurációs fájljai a /etc/init könyvtárban találhatók, így alapértelmezés szerint ott keresi őket, és végrehajtja az ebben a könyvtárban lévő konfigurációs fájlokban található shell parancsokat.

Upstart konfigurációs fájlok

Az Upstart init szolgáltatáskonfigurációs fájlokat használ a szolgáltatások vezérlésére, ellentétben a System V-ben használt bash parancsfájlokkal. Ezen szolgáltatáskonfigurációs fájlok elnevezési szabványa a következő: service_name.conf.

A fájlok egyszerű szöveges tartalmat tartalmaznak, amelyeket különböző, stanzáknak nevezett szakaszokra osztanak. Minden stanza egy szolgáltatás más-más állapotát és viselkedését írja le. A különböző stanzák a szolgáltatás különböző eseményeit vezérlik. Például: várakozás (waiting), indítás előtti (pre-start), indítás (start), leállítás előtti (pre-stop), leállítás (stopping) stb.

Egy stanza shell parancsokat tartalmaz, ami lehetővé teszi több művelet elindítását minden egyes eseményhez minden egyes szolgáltatásnál. Ezenkívül minden szolgáltatáskonfigurációs fájl a következő két dolgot határozza meg:

• Mely futási szinteken (runlevel) kell a szolgáltatásnak elindulnia és leállnia.
• Újra kell-e indulnia (respawn) a szolgáltatásnak, ha összeomlik.

Upstart könyvtárszerkezet

Az Upstart szolgáltatáskonfigurációs fájlok a /etc/init könyvtárban találhatók. Ne tévessze össze ezt a következővel:  /etc/init.d.

Upstart példa

Ebben a példában megnézzük, hogyan kezeli az Upstart a szolgáltatásokat a rendszerindítás során és összeomlás esetén. Részletesebben elmagyarázzuk az útmutató első részében bemutatott gyakorlati példákat.

1. lépés: Jelentkezzen be az Ubuntu 14.0.4 szerverre

Először az Upstart teszteléséhez a második VPS-t fogjuk használni, amelyen Ubuntu 14.0.4 fut. Ez azért van, mert ez a Linux disztribúció natívan implementálja az Upstartot. Használjon ssh-t vagy putty-t, ha Windows-t használ. Egy root vagy sudo jogosultságokkal rendelkező felhasználóval kell bejelentkeznie. Nekem van egy hackins nevű felhasználóm, így én így jelentkeznék be:

Helyettesítse a saját root/sudo felhasználójával és a szerver nyilvános IP-címével. Ezután  nyomja meg az Entert, és adja meg a jelszót vagy a jelmondatot.

2. lépés: Az init és rc könyvtárak vizsgálata

Az Upstart konfigurációs fájlok az /etc/init könyvtárban tárolódnak. Ezt a könyvtárat fogja használni új szolgáltatáskonfigurációs fájlok létrehozásakor.

Az /etc/init könyvtárban található konfigurációs fájlok neveinek kilistázásához futtassa a következő parancsot:

A fenti parancs kimenetéből látható, hogy számos szolgáltatás fut az Upstart alatt. Nyomja meg a Q billentyűt a less programból való kilépéshez.

Ha a következőt futtatja a System V szolgáltatáskonfigurációs fájljainak kilistázásához az rc könyvtárban, csak néhányat fog látni:

3. lépés: Egy Upstart fájl vizsgálata

Az útmutató első részében egy mysql.conf fájlt használtunk a szerverkonfiguráció megismeréséhez. Ismereteink bővítéséhez használjunk egy másik konfigurációt. A cron konfigurációs fájl jó jelölt erre. Írja be a következő parancsot a fájl megnyitásához:

Az alábbi képernyőképhez hasonló kimenetet kell kapnia:

A parancsfájl meglehetősen egyszerű. Vegye figyelembe a következő fontos mezőket: start on, stop on, fork, és respawn. Let’s define what these directives are doing:

• start on arra utasítja az Ubuntut, hogy indítsa el a cron démont, amikor a rendszer a 2-es, 3-as, 4-es vagy 5-ös futási szintre lép. Nem fog futni az itt meg nem határozott egyéb futási szinteken, azaz a 0-s, 1-es vagy 6-os szinten.
• stop on arra utasítja az Ubuntut, hogy állítson le egy futó démont. Ebben az esetben azonban van egy felkiáltójel (!), ami egy tagadójel. A parancsfájlt nem szabad leállítani a felkiáltójel utáni futási szinteken: 2,3,4,5.
• fork irányelv arra utasítja az Upstartot, hogy válassza le a folyamatot a konzolról, és hagyja futni a háttérben.
• respawn irányelv arra utasítja a rendszert, hogy automatikusan indítsa el a cron démont, ha az bármilyen okból összeomlik.

Nyomja meg a Ctrl X billentyűkombinációt a szerkesztőből való kilépéshez anélkül, hogy bármit is beírna.

A többi upstart konfigurációs fájl is ugyanezt a struktúrát követi, start, stop és respawn stanzákkal. Egyes konfigurációs fájlok további parancsfájl-blokkokat is tartalmazhatnak a pre-start, pre-stop, post-start és egyéb állapotokhoz. Ezek a kódblokkok megmondják a rendszernek, hogy mit kell végrehajtania, amikor egy folyamat a meghatározott állapotok bármelyikében van.

4. lépés: A MySQL szolgáltatás indítási viselkedésének tesztelése a rendszer felállása után

A MySQL alapértelmezés szerint automatikusan elindul a rendszer rendszerindítása után. Megpróbáljuk letiltani, és megnézzük a viselkedését. Az Upstartban egy szolgáltatást úgy lehet letiltani, hogy létrehozunk egy service_name.override nevű fájlt a /etc/init/ könyvtárban. A fájl tartalma mindössze egyetlen szó: manual.

Lássuk, hogyan használhatjuk ezt a parancsot a MySQL szolgáltatás letiltására. Írja be a következő parancsot a fájl nano szerkesztővel történő megnyitásához:

A megnyitott fájlba adja hozzá a következő sort:

Mentse a változtatásokat a Ctrl + O, majd az Enter billentyűk lenyomásával. Lépjen ki a szerkesztőből a Ctrl + X billentyűkombinációval. Futtassa a következő parancsot a szerver újraindításához:

Várjon néhány percet, majd jelentkezzen be újra. Miután újra bejelentkezett, tesztelje a MySQL szolgáltatás állapotát a következő parancs beírásával:

A kimenet azt fogja jelezni, hogy a szolgáltatás nem fut:

Ez azt jelzi, hogy a MySQL nem indult el automatikusan a rendszerindítás után. Ezután nyissa meg a MySQL konfigurációs fájlt, és ellenőrizze, hogy a start direktíva megváltozott-e:

A kimenet azt fogja jelezni, hogy semmi sem változott:

Ez azt jelenti, hogy ha a szolgáltatás nem indul el automatikusan, és Ön csak a szolgáltatás konfigurációs fájlját ellenőrzi (service_name.conf), előfordulhat, hogy nem találja a hibát. Ellenőriznie kell a service_name.override fájl meglétét is a könyvtárban.

Írja be a következő parancsot az override fájl törléséhez és a MySQL szolgáltatás újbóli engedélyezéséhez. Ezután indítsa újra a szervert:

Miután a szerver elindult, tesztelje újra a MySQL szolgáltatás állapotát:

Ennek azt kell mutatnia, hogy a MySQL szolgáltatás automatikusan elindult.

5. lépés: A MySQL szolgáltatás indítási viselkedésének tesztelése rendszerösszeomlás után

Alapértelmezés szerint a MySQL szolgáltatás automatikusan újraindul, ha összeomlik. Ennek a viselkedésnek a leállításához szerkeszteni fogjuk a mysql.conf fájlt. Írja be a következő parancsot a fájl nano szerkesztővel történő megnyitásához:

Keresse meg a respawn direktívasorokat, és kommentelje ki őket az alábbiak szerint a #:

Futtassa a következő parancsokat a szolgáltatás újraindításához:

A fenti parancsokat használtuk a szolgáltatás leállítására és elindítására, mert az initctl restart vagy az initctl reload használata itt nem működne. Amikor futtatja a MySQL szolgáltatás elindítására szolgáló parancsot, a kimenet egy ilyen PID-t fog megjeleníteni a MySQL-hez:

A mi PID-ünk 1439 volt. Ezután jegyezze fel, mit kapott a parancs futtatásakor, ezt a következő lépésben fogjuk használni. Az összeomlás szimulálásához lője le a MySQL folyamatot a következő paranccsal, ne felejtse el kicserélni a PID-et a fent leírtak szerint:

Annak ellenőrzéséhez, hogy a MySQL újraindult-e az összeomlás után, várjon néhány percet, majd írja be a következő parancsot:

A kimenet azt fogja jelezni, hogy a MySQL leállt:

Próbálja meg még néhányszor ellenőrizni az állapotot, hogy lát-e változást. Észre fogja venni, hogy a MySQL leállítva marad. Ez azért van, mert a szolgáltatás konfigurációs fájljában nincsenek meg a respawn direktívák (azok, amelyeket kikommenteltünk). Olvassa el az útmutató 1. részét a respawn direktíva részletesebb magyarázatáért.

Miért mutattuk meg, hogyan tilthatja le a szolgáltatások automatikus újraindítását a rendszer indítása vagy összeomlása után? Ez főként hibaelhárítási célokat szolgál. Ha például a szolgáltatás elindul, de folyamatosan összeomlik, érdemes lehet letiltani, hogy elvégezhesse a hibaelhárítást, és stabilan tartsa a rendszert. Megakadályozhatja néhány régi szolgáltatáskonfiguráció automatikus újraindítását is, ha véletlenül egy olyan új Linux disztribúcióra frissít, amely natívan tartalmazza a systemd rendszert, amelyet a következő szakaszban tárgyalunk.

A Systemd bemutatása

Systemd a legújabb init rendszer, amely a legfrissebb Linux disztribúciókban található meg. Számos olyan komponenst tartalmaz, amelyek egy modern Linux rendszert alkotnak.

Systemd nemcsak a szolgáltatásokat, hanem a teljes Linux rendszert is kezeli. Ebben a szakaszban arra fogunk összpontosítani, hogyan szabályozza a systemd a szolgáltatások viselkedését a rendszer indítása vagy összeomlása után.

A Systemd visszafelé kompatibilis a System V init parancsfájlokkal és parancsokkal. Ezért ha rendelkezik System V-re konfigurált szolgáltatásokkal, azok a Systemd alatt is futni fognak. A legtöbb Upstart és System V adminisztrációs parancsot módosították, hogy működjön a Systemd-vel. A Systemd rendszerindításkor átnevezi magát init-re. Létezik egy /sbin/init fájl, amely szimbolikus linkkel mutat a /bin/systemd.

Systemd konfigurációs fájlok: Unit fájlok

A Systemd konfigurációja unit fájlokból áll. Minden egyes unit fájl egy rendszererőforrást képvisel. Míg a másik két init rendszer (azaz a System V és az Upstart) a Linux rendszer szolgáltatásainak kezeléséért volt felelős, addig a Systemd nemcsak a szolgáltatás-démonokat kezeli, hanem más típusú rendszererőforrásokat is, mint például az eszközök operációs rendszerbeli útvonalait, socketeket, csatolási pontokat stb. Az egységfájlok az erőforrással kapcsolatos információkat tárolják.

Minden unit fájl egy adott rendszererőforrást képvisel, az alábbi elnevezési stílussal: service_name.unit_type. Ez azt jelenti, hogy olyan fájlokat fog találni, mint a home.mount, dbus.service, sshd.socket stb. A unit fájlok egyszerű szöveges fájlok, deklaratív szintaxissal, amely könnyen érthető és módosítható.

Könyvtárszerkezet

A natív unit fájlok fő helye a /lib/systemd/system/ könyvtár. Az Ön által létrehozott vagy a rendszergazdák által egyedileg készített unit fájlok, valamint az egyéb módosított natív unit fájlok a /etc/systemd/system könyvtárban tárolódnak.

Ha egy azonos nevű unit fájl létezik mind a /lib/systemd/system/ és a /etc/systemd/system könyvtárakban, a systemd az /etc könyvtárban lévőt fogja használni.

Amikor engedélyezi egy szolgáltatás elindulását rendszerindításkor vagy bármely más cél (target) / futási szint (runlevel) esetén, egy szimbolikus link jön létre az adott szolgáltatás unit fájljához a megfelelő könyvtárakban a /etc/systemd/system könyvtár alatt. Az /etc/systemd/system könyvtárban található unit fájlok csupán szimbolikus linkek a hasonló nevű fájlokra a /lib/systemd/system könyvtárban.

Systemd indítási sorrend: Target egységek

A target egységek a unit fájlok egyedi típusai, amelyek általában a .target utótaggal végződnek. A target egységek abban különböznek a többi unit fájltípustól, hogy nem egyetlen konkrét erőforrást képviselnek. Ehelyett a teljes rendszer egy adott időpontbeli állapotát képviselik.

Ennek eléréséhez a target egységek csoportosítanak és elindítanak több olyan unit fájlt, amelyek egy adott állapot részét képezik. Bár a Systemd targetek és a System V futási szintek (runlevels) lazán összehasonlíthatók, nem azonosak. Egy target unit fájlnak szám helyett neve van. Például a runlevel 3 helyett olyat talál, mint a multi-user.target, vagy a runlevel 6 helyett a reboot.target. Egy Linux rendszer elindulhat a multi-user.target használatával. Ebben az esetben ez alapvetően a 2-es, 3-as vagy 4-es futási szintre hozza a szervert, ami a rendszert többfelhasználós szöveges módban indítja el, engedélyezett hálózattal.

A különbség abban rejlik, hogyan hozza a szervert erre a szintre. A System V egymás után, szekvenciálisan indítja el a szolgáltatásokat. Ezzel szemben a rendszer indulásakor a systemd ellenőrzi, hogy léteznek-e más szolgáltatások vagy erőforrások, és meghatározza azok betöltési sorrendjét.

Egy másik különbség a systemd target egységek és a System V futási szintek között az, hogy a System V-öt használó Linux disztribúciók egyszerre csak egy futási szinten létezhetnek. Ha módosítja a futási szintet, az egyszerűen átvált az új futási szintre, és abban fog létezni. Ezzel szemben a target egységfájlok egymást magukban foglalóak is lehetnek. Továbbá egy target egység aktiválása biztosítja, hogy más target egységek is betöltődjenek annak részeként. Például, ha egy grafikus felhasználói felülettel rendelkező Linux rendszert indít el, azon a graphical.target lesz aktiválva. Ez viszont automatikusan biztosítja, hogy a multi-user.target is betöltődjön és aktiválódjon.

Íme egy táblázat, amely összehasonlítja a futási szinteket és a targeteket.

Futási szint (System V)	Target egységek (systemd)
runlevel 0	poweroff.target
runlevel 1	rescue.target
runlevel 2,3,4	multi-user.target
runlevel 5	graphical.target
runlevel 6	reboot.target

Systemd default.target

A systemd-ben a default.target a System V alapértelmezett futási szintjének felel meg. Láttuk, hogy a System V alapértelmezett futási szintje az inittab fájlban volt meghatározva. A systemd-ben a default.target fájl áll rendelkezésre. Az alapértelmezett target fájl a /etc/systemd/system könyvtárban található. Ez egy szimbolikus link (symlink), amely az alábbi könyvtárban lévő egyik target egységfájlra mutat: /lib/systemd/system. Az alapértelmezett target megváltoztatása egyszerűen a szimbolikus link újbóli létrehozását és a rendszer futási szintjének módosítását jelenti.

A System V-ben az inittab határozta meg, hogy a Linux melyik könyvtárban találja meg az init szkripteket. Ez a korábban bemutatott rc könyvtárak bármelyike lehetett. Ezzel szemben a systemd alapértelmezett targetje határozza meg a rendszerindításkor betöltendő erőforrás-egységeket. Minden meghatározott egység betöltődik. Azonban nem mindegyik töltődik be párhuzamosan, és nem mindegyik töltődik be egymás után. Az erőforrás-egység betöltése a többi olyan erőforrástól függ, amelyet az wants vagy requires.

Systemd függőségek: Wants és Requires

Ebben a szakaszban azt fogjuk megvitatni, hogyan kezeli a Systemd a függőségeket. Láttuk, hogy az Upstart segítségével a szolgáltatások párhuzamos betöltése lehetséges konfigurációs fájlok használatával. Arról is beszéltünk, hogy a System V hogyan használja a futási szinteket annak meghatározására, hogy melyik szolgáltatás induljon el automatikusan, vagy várjon-e, amíg egy másik szolgáltatás vagy erőforrás elindul. Hasonlóképpen, a Systemd szolgáltatások is konfigurálhatók úgy, hogy egy vagy több targetben töltődjenek be, vagy várjanak, amíg egy másik szolgáltatás vagy erőforrás elindul.

A Systemd-ben az az egységfájl, amely requires egy másik egységet, nem fog elindulni, amíg a megkövetelt egység be nem töltődik és aktívvá nem válik. Ha a megkövetelt egység betöltése sikertelen, miközben az első egység aktív, az első egység leáll.

Ez a viselkedés biztosítja a rendszer stabilitását. Egy olyan szolgáltatás, amely requires egy adott erőforrás (például egy port) rendelkezésre állását és aktivitását igényli, így várakoztatható, amíg az erőforrás elérhetővé nem válik (azaz a port meg nem nyílik).

Ezzel szemben egy olyan egység, amely wants egy másik egységet, nem támaszt ilyen korlátozásokat. Nem fog leállni, ha a kért egység leáll, miközben a hívó egység még aktív. Ilyenek például a grafikus célmódban (graphical-target) lévő egyes nem létfontosságú szolgáltatások.

Systemd példa

Lássuk, hogyan konfigurálhatjuk egy szolgáltatás viselkedését systemd alatt.

1. lépés: Jelentkezzen be a VPS-példányába

A MySQL-t fogjuk használni valós szolgáltatásként, a szerver pedig a CentOS 7 lesz. A lépések gyakorlati végrehajtásához és a fogalmak megértéséhez jelentkezzen be a CentOS 7 VPS-ébe, vagy hozzon létre egyet a CloudSigma-n. Egy CentOS 7, Debian 7 vagy 8, illetve Ubuntu 15 vagy újabb disztribúciót futtató VPS megfelelő ehhez a szakaszhoz, mivel mindegyik tartalmazza a systemd-t. Jelentkezzen be az ssh paranccsal, vagy ha Windowst használ, használja a PuTTY-t:

2. lépés: A default.target fájl és a függőségek vizsgálata

A Systemd indítási folyamata a függőségek hosszú láncolatát követi, amelyet ebben a szakaszban részletesen megvitatunk.

• default.target

A default.target fájl vezérli a normál rendszerindítás során elinduló szolgáltatásokat. Az alapértelmezett target egységfájlt a következő paranccsal listázhatja ki:

A kimenet az alábbi képernyőképhez hasonlót mutat:

A képernyőképen látható, hogy az alapértelmezett target a multi-user.target fájlra mutat a /lib/systemd/system/ könyvtár. Ez azt jelenti, hogy alapértelmezés szerint a rendszer a multi-user.target alatt fog elindulni, ami megegyezik a következővel: runlevel 3.

• multi-user.target.wants

A multi-user.target fájl által igényelt összes szolgáltatás megtekintéséhez írja be a következő parancsot:

A kimenet sok sort tartalmaz, íme egy részlet:

Ahogy a kimenet mutatja, ezek szimbolikus linkek, amelyek a tényleges egységfájlokra mutatnak a /lib/systemd/system/ könyvtárban. Kiemeltük a mysqld.service szolgáltatást, hogy megmutassuk, ez is a multi-user.target része. Ha ellenőrizni szeretné, hogy egy bizonyos szolgáltatás be van-e állítva az indításra, módosíthatja az adott fájlra vonatkozó parancsot. Például a következő parancsokkal szűrhetjük a kimeneteket a mysql vagy a cron démon megtalálásához:

A kimenet a következőt fogja mutatni:

A cron démonra vonatkozó eredmény szűréséhez írja be a következő parancsot:

A kimenet a következőt fogja mutatni:

A multi-user.target mellett más típusú célok is léteznek, pl. system-update.target vagy basic.target.

Írja be a következő parancsot, hogy megtekinthesse, milyen céloktól függ a multi-user target:

A kimenet a következőt mutatja:

Ez azt jelenti, hogy a basic-target egységnek kell először betöltődnie ahhoz, hogy a rendszer multi-user.target módban induljon el.

• basic-target

Írja be a következő parancsot, hogy megtekinthesse, milyen más célokat igényel a basic.target:

A kimenet a következőt fogja mutatni:

• sysinit.target

A következő parancs futtatásával ellenőrizheti, hogy vannak-e szükséges targetek a következőhöz: sysinit.target. A parancs szintaxisa megegyezik. Folyamatosan módosíthatja, hogy lássa, melyik target egységet melyik másik target egység igényli. Íme a parancs:

A kimenet azt fogja mutatni, hogy nincsenek szükséges egységek a következőhöz: sysinit.target. Ellenőrizhetjük, hogy vannak-e más szolgáltatások és targetek, amelyek szükségesek a sysinit.target számára, a következő parancs használatával:

A kimenet a(z) sysinit.target által igényelt szolgáltatások és targetek hosszú listáját mutatja. A kimenet egy része alább látható:

A system4 segítségével történő rendszerindítás során a rendszer nem csak egyetlen targetben marad. Ehelyett a szolgáltatásokat függőségi sorrendben tölti be, miközben egyik targetről a másikra lép át.

3. lépés: Egy unit fájl megvizsgálása

Lássuk, hogyan néz ki egy unit fájl. Az útmutató első részében a MySQL szolgáltatás unit fájlját használtuk, és most is azt fogjuk használni. Azonban megnézhetünk egy másik szolgáltatás unit fájlt is – az sshd unit fájlt. Írja be a következő parancsot az sshd konfigurációs fájl megnyitásához:

Az alábbi képernyőkép a fájl sorait mutatja:

Mint látható, a fájlban vázolt kódblokkok megkönnyítik a megértést és a szükség szerinti módosítást. Az alábbiakban bemutatunk néhány fontos irányelvet, amelyeket érdemes megérteni:

• After – az After záradék arra utasítja a rendszert, hogy a szolgáltatást csak a megadott targetek és szolgáltatások betöltése után töltse be. Ebben az esetben az SSHD szolgáltatás a hálózati target és a keygen szolgáltatás betöltése után fog betöltődni.
• Wants – a Wants záradék megmutatja, hogy mely targetek igénylik ezt a szolgáltatást. Ebben az esetben az ssh-keygen.service igényli az sshd.service szolgáltatást. Ha azonban az sshd meghiúsul vagy összeomlik, az nem fogja leállítani a ssh-keygen.service.

Nyomja meg a Ctrl + X billentyűkombinációt a szerkesztő bezárásához.

4. lépés: A MySQL szolgáltatás indítási viselkedésének tesztelése rendszerindításkor

Ebben a részben megmutatjuk, hogyan módosíthatja és tesztelheti a MySQL szolgáltatás viselkedését a rendszer indításakor. Az előző részben láthattuk, hogy a mysqld.service szolgáltatást igényli a multi-user.target. Ezért a rendszerindításkor automatikusan elindul.

A szolgáltatást a következő parancs futtatásával tilthatja le:

A parancs futtatása azt mutatja, hogy a mysql szimbolikus link el lett távolítva a /etc/systemd/system/multi-user.target.wants/ könyvtárból. Ennek teszteléséhez futtassa a következő parancsot, amellyel ellenőrizheti, hogy a MySQL-t továbbra is igényli-e a multi-user.target:

A parancs nem ad vissza semmit. Ha megpróbálja újraindítani a szervert és ellenőrzi a MySQL állapotát, az nem fog futni, ami azt jelenti, hogy nem indult el automatikusan a rendszerindításkor.

Most engedélyezze újra a szolgáltatást a következő paranccsal:

A kimenet egy szimbolikus linket fog mutatni. Ha újraindítja a szervert, a MySQL-nek automatikusan el kell indulnia. Egy Systemd szolgáltatás engedélyezése létrehoz egy szimbolikus linket az alapértelmezett cél wants könyvtárában. Egy Systemd szolgáltatás letiltása eltávolítja a szimbolikus linket a wants könyvtárból.

5. lépés: A MySQL szolgáltatás indítási viselkedésének tesztelése szolgáltatás-összeomlás után

Alapértelmezés szerint a MySQL szolgáltatás automatikusan újraindul, ha összeomlik. Ezt a viselkedést letilthatjuk a MySQL Systemd konfigurációs fájljában. Először vessünk egy pillantást a fájlra. Írja be a következő parancsot a fájl megnyitásához:

Az alábbi képernyőkép mutatja a kimenetet:

A Restart direktíva értéke on-failure-re van állítva. Ez azt jelenti, hogy a MySQL szolgáltatás újraindul a nem tiszta kilépési kódok, időtúllépés vagy nem tiszta szignálok után. Az alábbi táblázat bemutat néhány újraindítási paramétert a kézikönyv oldalt.

Újraindítási beállítások/Kilépési okok	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
szabályos kilépési kód vagy szignál		X	X
Nem tiszta kilépési kód		X		X
Nem tiszta szignál		X		X	X	X
Időtúllépés		X		X	X
Watchdog		X		X	X		X

A Systemd unit fájl két fontos direktívája a Restart és a RestartSec. Ezek vezérlik a szolgáltatás összeomlás utáni viselkedését. Restart határozza meg, mikor kell a szolgáltatásnak újraindulnia, a RestartSec pedig azt, hogy mennyi ideig kell várnia az újraindítás előtt egy összeomlás után. Az újraindítási viselkedés letiltásához fűzzön megjegyzést a Restart direktívához egy # karakter hozzáadásával a sor elejére, az alábbiak szerint:

Most töltse be újra a rendszer démont, majd töltse be újra a mysqld szolgáltatást a következő parancsokkal:

Ezután futtassa a következő parancsot a MySQL szolgáltatás fő PID-jének (Main PID) megkereséséhez:

A tesztünkben a fő PID a 23809 volt. Jegyezze fel a sajátját a következő parancshoz. A kill -9 parancs használatával szimuláljon egy összeomlást a folyamat leállításával. Ne felejtse el kicserélni a teszt során kapott folyamatszámmal:

Ha futtatja a MySQL állapotát ellenőrző parancsot, azt fogja tapasztalni, hogy nem aktív, és nem tudott újraindulni:

Mindaddig hibás (failed) állapotban marad, amíg a Restart direktíva ki van kommentelve a mysqld.service konfigurációs fájlban. Ez egy olyan összeomlást szimulál, amelyben a szolgáltatás leáll, és nem indul újra.

A szolgáltatás újbóli engedélyezéséhez szerkesztheti a mysqld.service konfigurációs fájlt, kiveheti a megjegyzést a Restart direktíva elől, majd mentheti és bezárhatja. Ahogy korábban tette, töltse be újra a démont, és indítsa újra a szolgáltatást. Ez visszaállítja a szolgáltatást a kezdeti konfigurációjára, és most már automatikusan el tud indulni egy összeomlás után. Végezetül, ennyi a szolgáltatás összeomlás utáni automatikus újraindulásának konfigurálása. Ha szeretné beállítani a szolgáltatások automatikus újraindulását összeomlás után, egyszerűen hozzá kell adnia a Restart direktívát (és ha szeretné, a RestartSec direktívát is hozzáadhatja) a szolgáltatás unit fájljának [Service] szakaszában.

Összegzés

Ebben az útmutatóban áttekintettük, hogyan kezeli a Linux a szolgáltatásokat a rendszerindítás során vagy egy összeomlás után. A Linux rendszerindítási folyamatának megértéséhez bemutattuk a Linux által használt három init rendszert: a System V-öt, az Upstartot és a Systemd-t. Megvitattuk a fejlődésüket, és azt, hogy az egyes init folyamatok hogyan működnek a szolgáltatások automatikus elindításával kapcsolatban a rendszer újraindítása vagy összeomlása után.

Mivel mind az init démonok, mind a Linux disztribúciók folyamatosan fejlődnek az idők során, ne feledje el ellenőrizni az Ön által futtatott Linux disztribúció verzióját, hogy tudja, melyik init démont támogatja a rendszere natívan.

A natív Linux-alkalmazások és a legtöbb harmadik féltől származó alkalmazás már automatikusan elindul a rendszer indítása vagy összeomlása után, így Önnek semmit sem kell tennie. Az ebben az útmutatóban található ismeretek kulcsfontosságúak, amikor saját egyedi szolgáltatásainak indítási és újraindítási viselkedését konfigurálja, vagy amikor folyamatosan összeomló szolgáltatások hibáit hárítja el.

Kellemes számítógépezést!