A fájlformátum valójában közel van az ini-hez. Tudom, hogy furcsa lehet, mivel az ini fájlokat gyakran megtalálják a Windows-ban, de ez így működik. A szolgáltatásfájl először 2 szakaszra oszlik: [Egység] és [Szerviz]. Minden szakasz a systemd egy meghatározott aspektusát konfigurálja: Az [Unit] az összes systemd unit fájl által megosztott elemeket tartalmazza, míg a [Service] csak egy új szolgáltatás beállításához szükséges konfigurációhoz használható.

Ezután a szakasz olyan tulajdonságokkal van konfigurálva, mint a Description = vagy az ExecStart =. Az értéket a tulajdonság nevétől az = egyenlőségjel választja el szóköz nélkül.

Térjünk vissza a fent látható fájlhoz. Olyan szolgáltatást ír le, amelyet a pingvinekről Pythonban írt webalkalmazás futtatására terveztek. A systemd akkor indítja újra, amikor a folyamat kilép és elindítja a szervert a szerver indításakor, ha engedélyezi a systemctl enable paranccsal. Menő, na?

De talán Ön a következő webalkalmazása nem a pingvinekről szól - és ez szégyen - és nem Pythonban van írva. Ebben az esetben többet szeretne megtudni a lehetséges konfigurációkról.

A Systemd Services tulajdonságai

Először koncentráljunk a [Unit] tulajdonságaira:

A Description = csak arról szól, hogy világosan leírják, mit csinál a szolgáltatás. Megjelenik a szolgáltatáslistában, a szolgáltatásnaplókban, hogy leíró jellegű legyen, de egy sorban és egy mondatban kell maradnia.

WantedBy = lehetővé teszi azt mondani a systemd-nek: amikor ez a dolog elindul, engem is elindít. Általában meg kell adnia a cél nevét. Példák a közös célokra:

1. többfelhasználós.target: ha a szerver rendben van, és készen áll a parancssori alkalmazások futtatására
2. grafikus.target: amikor a GNOME vagy a KDE készen áll
3. hálózat felépítése.cél: ha a szerver megfelelően van csatlakoztatva egy hálózathoz

A kezdethez rendben van az [Unit] ezen tulajdonságai. Vessünk egy pillantást a [Szolgáltatás] -ra.

A Type = segít a systemd-nek abban, hogy megtudja, fut-e egy szolgáltatás. Íme a gyakori típusok:

1. valószínűleg az egyszerű a leggyakrabban használt: a systemd az Ön által elindított folyamatot tekinti a szolgáltatónak. Ha a folyamat leáll, akkor a szolgáltatást is leállítja, stb.
2. A forking előnyös azoknál az alkalmazásoknál, amelyeket szerverként írtak, de szolgáltatáskezelő rendszer segítsége nélkül. Alapvetően arra számít, hogy az elindított folyamat elágazik, és ezt a villát tekintik a szolgáltatás végső folyamatának. A pontosság érdekében segíthet a systemd-n egy PID-fájlban is, ahol a követendő folyamat PID-jét az indított alkalmazás írja.

Az ExecStart = valószínűleg a legfontosabb a szolgáltatás szempontjából: pontosan megadja, hogy melyik alkalmazást indítsa el a szolgáltatás indításakor. Mint a Penguin szolgáltatásban láthatja, a / usr / bin / python3 fájlt használtam, és nem azonnal a python3 fájlt. Ez azért van, mert a systemd dokumentáció kifejezetten az abszolút utak használatát javasolja a meglepetések elkerülése érdekében.

De ez egy másik okból is. Az egyéb szolgáltatások irányítási rendszere általában a Shell szkriptjein alapszik. Azonban a systemd, a teljesítmény miatt, alapértelmezés szerint nem futtat egy héjat. Tehát nem adhat meg közvetlenül egy shell parancsot az ExecStart = fájlban. Ugyanakkor továbbra is használhat egy shell parancsfájlt az alábbiakkal:

Nem olyan nehéz? Ne feledje, hogy ha valamilyen folyamatot le kell futtatnia a szolgáltatás tiszta leállításának jelzésére, akkor létezik az ExecStop =, valamint a szolgáltatások újratöltéséhez az ExecReload =.

Restart = lehetővé teszi, hogy kifejezetten megmondja, mikor kell újraindítani a szolgáltatást. Ez a systemd egyik fontos tulajdonsága: biztosítja, hogy szolgáltatása mindaddig fennmaradjon, ameddig csak szeretné, ezért nagyon figyeljen erre a lehetőségre.

WorkingDirectory = kényszeríthet egy működő könyvtárat az alkalmazás indításakor. Az értéknek abszolút könyvtár útvonalnak kell lennie. A munkakönyvtár akkor használható, ha relatív elérési utakat használ az alkalmazás kódjában. A pingvinek szolgálatában ez lehet:

Ezután fontos a biztonság, ezért általában nem kívánja root szolgáltatásokkal indítani a szolgáltatást. A User = és a Group = lehetővé teszi annak a felhasználói vagy csoportnévnek vagy UID / GID-nek a beállítását, amely alatt az alkalmazás elindul. Például:

A EnvironmentFile = egy hatékony lehetőség. A szolgáltatásként futó alkalmazásoknak gyakran van szükségük konfigurációra, és a környezeti fájlok lehetővé teszik a konfiguráció kétféle módon történő beállítását:

1. Az alkalmazás közvetlenül el tudja olvasni a környezeti változót.
2. Ugyanakkor különböző parancssori argumentumokat is beállíthat az alkalmazásához a szervizfájl megváltoztatása nélkül.

A fájl szintaxisa egyszerű: beírja a környezeti változó nevét, az egyenlőségjelet =, majd annak értékét. Ezután beírja a környezeti fájl abszolút elérési útját a EnvironmentFile tulajdonságba.

Tehát példa:

Az / etc / penguin-web-app / environment fájl a következőket tartalmazza:

Ezután pingvinek webalkalmazásunk hozzáfér a LISTEN_PORT környezeti változóhoz, és meghallgatja a várható portot.

Mentse és indítsa el az újonnan létrehozott Systemd szolgáltatást

Tehát, ha betartotta a tanácsomat, szerkesztette a szolgáltatási fájlt a saját könyvtárában. Ha elégedett, másolja a fájlt a / usr / local / lib / systemd / system fájlba, feltételezve, hogy a disztribúció támogatja ezt az utat. A szolgáltatási fájl fájlneve a szolgáltatás neve lesz. Ennek a fájlnévnek véget kell vetnie .szolgáltatás. Például a pingvinek szerverünk számára ez a pingvin-web-alkalmazás lenne.szolgáltatás.

Ezután el kell mondania a systemd-nek, hogy új szolgáltatást adott hozzá, ezért be kell írnia ezt a parancsot:

Oké, most a systemd tisztában van az új szolgáltatással, feltételezve, hogy a fájl nem tartalmaz szintaktikai hibát. Végül is ez az első fájlja, így valószínű, hogy hibázik. Ezt a parancsot a szolgáltatásfájl minden frissítésénél futtatnia kell.

Itt az ideje a szolgáltatás elindításának:

Ha nem sikerül egy Unit not found hibával, mint ez:

Ez azt jelenti, hogy a terjesztés nem támogatja a könyvtárat, vagy nem megfelelően nevezte el a szervizfájlt. Feltétlenül nézd meg.

Ha a WantedBy = szolgáltatással állította be szolgáltatását, és azt szeretné, hogy a szolgáltatás automatikusan elinduljon, akkor ezt a parancsot kell engedélyeznie:

Az a jó dolog egy szolgáltatásnál, hogy a háttérben fut. A probléma: hogyan lehet tudni, hogy megfelelően működik-e, és ha a háttérben fut?? Ne aggódjon, a systemd csapat is gondolt erre, és adott egy parancsot, hogy ellenőrizze, hogy megfelelően működik-e, mivel mennyi idő stb.:

Következtetés

gratula! Mostantól úgy kezelheti az alkalmazásokat, hogy nem törődik azzal, hogy minden alkalommal újraindítsa manuálisan. Most azt javaslom, hogy olvassa el a systemd naplókról szóló másik cikkünket: Master journalctl: a systemd naplók megértése. Ezzel használhatja az erőteljes naplózási rendszert új szolgáltatásában, és megbízhatóbb szervereket készíthet!