Hogyan lehet automatikusan elindítani a szolgáltatásokat a rendszerindításkor az RHEL / CentOS 7 rendszerben?

Kíváncsi, hogyan kezelheti a szolgáltatásokat a háttérben vagy a rendszerindításkor?


Megváltozott a rendszerindítási folyamatok kezelésének és indításának mechanizmusa. Az RHEL / CentOS 6.x-ig a /etc/init.d/ könyvtárban létrehozott volna egy szkriptet, amely a chkconfig segítségével engedélyezve lett, de a dolgok másképp vannak RHEL 7.

Ezt felváltja a systemd, és mivel a Linux nagyobb verzióinál ez többé-kevésbé az alapértelmezett folyamatkezelő, a System Admin más ízeket is megismerve otthon érezheti magát. Ebben a cikkben azt vizsgáljuk meg, hogy mi a systemd, mi volt a váltás oka, és hogyan lehet használni a systemd-t a háttérfolyamatok beállításához, futtatásához és kezeléséhez.

Mi a rendszer??

Mivel a Linuxban minden folyamat átláthatóan látható, nézzük meg, hol reked a systemd. Rendszeren a következőket kapom:

~ $ ps -ef | grep systemd
root 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd –system –deserialize 22
üzenet + 768 1 0 november 11? 00:05:46 / usr / bin / dbus-démon – rendszer – cím – = rendszerd: –nofork –nopidfile – rendszer-aktiválás – csak syslog-csak
root 805 1 0 Nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 Nov11? 00:00:00 / lib / systemd / systemd –user
ankush 1176 1132 0 november 11? 00:04:50 / usr / bin / dbus-daemon –keresés – cím = systemd: –nofork –nopidfile – systemd-activation –syslog-only
ankush 9772 20029 0 21:11 pont / 6 00:00:00 grep –color = auto systemd
systemd + 17298 1 0 november 19? 00:00:12 / lib / systemd / systemd-feloldva
systemd + 17303 1 0 november 19? 00:00:00 / lib / systemd / systemd-timesyncd
gyökér 17307 1 0 november 19? 00:00:02 / lib / systemd / systemd-napló
gyökér 18182 1 0 november 19? 00:00:00 / lib / systemd / systemd-udevd

Fogadok, hogy azonnal észrevette. A listában az első folyamat felhasználói gyökérként indult, és pid 1-vel rendelkezik.

Természetesen ez volt az első folyamat, amelyet a rendszer indításkor indított. Köszönj a systemd-nek. ��

Tehát egész egyszerűen, a systemd az „anya” folyamat, amely elindítja, kezeli és leállítja a rendszer többi folyamatát, azon kívül, hogy információkat szolgáltat a naplózásáról, a fájlrendszer állapotáról stb..

Megjegyzés a névhez. A név valóban rendszerezett, és nem a D rendszer, vagy bármi más. A „d” a démonra utal, egy szokásos Linux folyamat, amely a háttérben működik (elárasztódik?), És nincs csatolva egyetlen terminálszekcióhoz..

Miért váltott az RHEL a rendszerre?

Mint már tárgyaltuk, a systemd egy rendszer- és folyamatkezelő, és az RHEL 7-ben a jól ismert Upstart programot váltja fel. Miért hozta ezt a döntést az RHEL (Oracle?)? Nos, ennek nagyon jó okai vannak, szóval vessünk egy pillantást.

Párhuzamos szolgáltatás inicializálása

Mivel nem érti a SysV init programot, a systemd képes párhuzamosan szolgáltatásokat indítani. Az init program ezzel ellentétben elindítja őket egyenként. Egy olyan korban, amikor még a mobil eszközöknek is többmagos CPU-ja van, a párhuzamos inicializálás hiánya nagy kikapcsolás.

Dinamikus (forró) szolgáltatás menedzsment

Ha észrevette, hogy az USB-meghajtókat kifejezetten be kell építeni a korábbi Fedora rendszerekbe, miközben automatikusan kinyílik az Ubuntu és hasonló disztribúciókban, az oka rendszerezett. Képes felismerni a hardverben bekövetkező élő változásokat, és szükség szerint leállíthatja / indíthatja a szolgáltatásokat. Néhányan azt állíthatják, hogy felesleges, ám sokuk számára üdvözlendő minden, ami csökkenti a kognitív terheket.

A szolgáltatás elhalasztása

A systemd lerövidíti a rendszerindítási időket, mivel képes elhalasztani a szolgáltatás indítását, amikor az valóban szükséges. Egy egyszerű példa a hálózati fájlrendszerrel kapcsolatos szolgáltatások. Ha nincs elérhető hálózati lemez, akkor nincs értelme egy szolgáltatás felállításának és futtatásának.

A folyamatok gyorsabb kommunikációja

A systemd párhuzamos képességei átviszik a folyamatok közötti kommunikációt. A systemd képes párhuzamos hozzáférést biztosítani a foglalatokhoz és a rendszerbuszhoz, jelentősen csökkentve a kommunikációs erőforrások folyamatvárakozási idejét.

Automatikus újraindítás

Ha egy szolgáltatás összeomlik, a systemd észlelheti ezt, és megpróbálja újraindítani. Leggyakrabban az egyszerű újraindításhoz elengedhetetlen az alkalmazás újbóli működésének megkezdése, kivéve ha alapvető kérdések merülnek fel.

Különben is, a systemd megkönnyíti a sysadmin életét itt.

systemd az RHEL7-ben – Mi változik a Sysadmins-en?

Ha hátrányos érzésed van róla, hogy a rendszerrendszer nem minden harang és síp, akkor igaza van. Van néhány jelentős összeférhetetlenség, amelyek meglepő módon tudják elragadni az RHEL sysadmin-et. Vessen egy pillantást.

Korlátozott szintű támogatás

A systemd meglehetősen szégyenletesen ismeri és támogatja a futási szinteket. Nem minden futási szintet támogat, és egyes céloknál esetleg még nem is létezik. Ilyen esetekben a systemd az „N” értéket adja vissza a futási szint parancsokra adott válaszként, jelezve, hogy ennek a célnak nincs megfelelő futási szintje. Összességében a Red Hat azt tanácsolja nekünk, hogy ne használjuk (!) A futási szint parancsokat.

Nincs egyedi parancs

Ez fájni fog. A SysV egyik nagy pluszát képezte az egyéni parancsok meghatározása, hogy jobb funkcionalitást biztosítson a folyamatok kezelésére. A rendszerezett rendszernél nincs ilyen lehetőség, és elakad a start, stop, status, restart stb. Funkciókkal.

Csak családi és nem interaktív

A systemd (természetesen) nyomon követi az indított folyamatokat, és tárolja a PID-ket. A kihívás azonban az, hogy a rendszered nem tud kezelni azokat a folyamatokat, amelyeket nem indított el. Ezenkívül a felhasználónak nincs lehetősége kölcsönhatásba a systemd által indított folyamattal. Az összes kimenet a / dev / null könyvtárba kerül, hatékonyan véget vetve a kimenetek rögzítéséhez fűződő reményeinek.

Nincs kontextus

Az init szolgáltatásokkal ellentétben a systemd által indított szolgáltatások nem öröklik a környezetet a rendszer egyik felhasználójától sem. Más szavakkal, olyan információk, mint a PATH és más rendszerváltozók nem állnak rendelkezésre, és minden új folyamat üres kontextusban indul el.

Ha ez a korlátozások listája sír, akkor ismét nem vagy egyedül. A systemd polarizáló erőként hatott a Linux világában, és a „systemd sucks” -el kapcsolatos Google-ok rengeteg olvasóanyagot eredményeznek. ��

Hogyan indíthatjuk el automatikusan a szolgáltatást, ha nem működik?

Ez egy nagyon gyakori eset a telepítéseknél. A programot olyan nyelven kell daemonizálnunk, amely nem rendelkezik hosszú ideje futó folyamatokkal: PHP! Tegyük fel, hogy PHP szkriptet írok a bejövő webkapcsoló kapcsolatok kezelésére (elvégre beszélgető alkalmazást építettünk fel!), És a szkript a /home/ankush/chat_server/index.php címen található..

Mivel a webes kapcsolatok bármikor elérhetik a kiszolgálót, ennek a folyamatnak mindig folyamatban kell lennie, és figyelnie kell a bejövő kapcsolatokat. Itt nem lehet a hagyományos PHP életciklus, mert a WebSockets állapotalapú kapcsolatok, és ha a szkript meghal, akkor a kapcsolat egy lista. Akárhogy is, elegendő a weboldalakon; lássuk, hogyan fogunk ezt a szkriptet a rendszeren keresztül daemonizálni.

Az összes rendszeres szolgáltatás az / etc / systemd / system fájlban található, tehát hozzunk létre egy fájlt ott, hogy leírhassuk a webes szerver szkriptünket. Feltételezve, hogy root felhasználóként van bejelentkezve.

# vi /etc/systemd/system/chat_server.service

és akkor a következőkre van szükség.

[Mértékegység]
Leírás = Chat szerver szolgáltatás
Miután = network.target

[Szolgáltatás]
Type = egyszerű
User = Ankush
ExecStart = php /home/ankush/chat_server/index.php
Restart = on-abort

[Telepítés]
WantedBy = multi-user.target

Mentse el a fájlt, és a következő lépés a systemd démon újratelepítése

# systemctl démon-újratöltés

és elindíthatjuk az éppen létrehozott szolgáltatást:

# systemctl indítsa el a chat_ szervert

Ha nem látsz hibát, akkor az volt az!

Gyorsan vessünk egy pillantást arra is, hogy mit jelentenek a fájlban szereplő különféle irányelvek:

  • Az [Unit] rész meghatároz egy új szerviz egységet a systemd számára. A szokásos szóhasználatban az összes szolgáltatás szolgáltató egység.
  • Az After irányelv (kiszámíthatóan) azt mondja a systemd-nek, hogy csak a hálózati szolgáltatások elindítása után indítsa el ezt a szolgáltatást (különben ki fogja kezdeni az aljzatbeli csatlakozók kezelését ?!).
  • A Type = simple azt mondja a systemd-nek, hogy ennek a szolgáltatásnak nem szabad önmagát villáznia. Más szavakkal, egy időben csak egy példány fut.
  • User = ankush azt jelenti, hogy ez a szolgáltatás „ankush” felhasználóként fog futni. Megváltoztathatjuk ezt „gyökérre”, de biztonsági szempontból nagyon nem ajánlott.
  • Az ExecStart, amint elmondhatja, a tényleges futtatáshoz szükséges parancs.
  • Újraindítás = megszakítás azt jelenti, hogy a szolgáltatást újra kell indítani, amikor megszakítja. A PHP-ben a hosszú ideig futó folyamatok szivárognak a memóriából, és végül felrobbannak, tehát erre szükség van.
  • A WantedBy = irányelv megmondja a systemd-nek, hogy mely célponthoz (gondoljon csoportokra) ez a szolgáltatás tartozik. Ennek eredményeként a szolgáltatáson keresztül mutató szimbolikus hivatkozások jönnek létre a célban.

Általában elegendő ez a háttérfolyamatok futtatásához, a systemd használatával az RHEL 7-ben.

További lehetőség a logika újraindításához

A fenti példában konfiguráltam az Újraindítás = megszakítás lehetőséget, de ez nem az egyetlen lehetőség. Több van, és a követelmény alapján választhat.

  • on-hiba – újraindul, ha tisztátalan kilépési kód vagy jel
  • mindig – Indítsa újra, ha megtalálja, tiszta vagy tisztátalan jelzés
  • on-kóros – tisztátalan jelzés, figyelő vagy időtúllépés
  • on-siker – csak akkor, ha egy tiszta jel vagy kilépési kód megállította

A szolgáltatás konfigurálása a rendszerindítás indításához

Miután elégedett vagy a szkripttel, és ellenőrizte, hogy működik-e, ezt a következő módon kell konfigurálnia, így indul és indul.

Lépjen az / etc / systemd / system mappába és hajtsa végre az alábbiakban az engedélyezés parancsot (ne felejtsd el megváltoztatni a .service fájl nevét a meglévővel)

# systemctl engedélyezze a chat_server.service szolgáltatást

Látni fogja annak megerősítését, hogy létrehozott egy hivatkozást.

Létrehozott hivatkozás az /etc/systemd/system/multi-user.target.wants/chat_server.service oldalról az /etc/systemd/system/chat_server.service oldalra.

Indítsa újra a szervert, és látnia kell, hogy a szolgáltatás elindul a rendszerindításkor.

Az könnyű volt! Nem igaz??

Segítség! Hatalmasan fektettem be az Upstartot. ��

Megértem, hogy bízik bennem, az eset inkább a norma, mint kivétel. Az RHEL olyan régóta használja az Upstartot, hogy a kapcsoló csaknem árulásnak érzi magát. De hé, a rendszerek folyamatosan változnak, és nem szabad összecsapnunk az apróságok felett. A Red Hat felismeri, hogy sok ember megragadt a régebbi verziókkal, és létrehoztak egy migrációs útmutató amire feltétlenül utalnia kell.

Ennek egyik megtakarító kegyelme az, hogy a systemd kompatibilis a SysV init parancsfájlokkal, tehát nagyrészt egyszerűen át kell helyeznie a fájljait, és ugyanazokat a szolgáltatásokat kell futtatnia..

Szeretne többet megtudni a Linux adminisztrációjáról és a hibaelhárításról? Nézd meg ezt online tanfolyam.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map