Kako samodejno zagnati storitve ob zagonu v RHEL / CentOS 7?

Se sprašujete, kako upravljati storitve v ozadju ali ob zagonu?


Spremenjen je mehanizem za upravljanje in zagon procesov pri zagonu. Do RHEL / CentOS 6.x bi v /etc/init.d/ ustvarili skript in ga omogočili s pomočjo chkconfig, vendar so stvari drugačne na RHEL 7.

Nadomestil ga je systemd, in ker je v večjih različicah Linux bolj ali manj privzeti vodja procesov, se bo sistemski skrbnik, ki je seznanjen z drugimi okusi, počutil kot doma. V tem članku bomo raziskali, kaj je sistemd, kateri so bili razlogi za preklop in kako s sistemdom vzpostaviti, zagnati in upravljati procese v ozadju z njim.

Kaj je sistemsko?

Ker je vsak postopek v Linuxu pregleden, poglejmo, kje sistem skriva. V mojem sistemu dobim naslednje:

~ $ ps -ef | grep sistem
root 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd –sistem – deserializiraj 22
sporočilo + 768 1 0 Nov11? 00:05:46 / usr / bin / dbus-daemon – sistem – naslov = systemd: –nofork –nopidfile – aktivacija sistema – samo za sistem
root 805 1 0 nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 nov11? 00:00:00 / lib / systemd / systemd – uporabnik
ankush 1176 1132 0 nov11? 00:04:50 / usr / bin / dbus-daemon – sesija – naslov = systemd: –nofork –nopidfile – sistemsko aktiviranje – samo za sistem
ankush 9772 20029 0 21:11 pts / 6 00:00:00 grep –barva = samodejno systemd
systemd + 17298 1 0 Nov19? 00:00:12 / lib / systemd / systemd-razrešena
systemd + 17303 1 0 Nov19? 00:00:00 / lib / systemd / systemd-timesyncd
root 17307 1 0 nov19? 00:00:02 / lib / systemd / systemd-journald
koren 18182 1 0 nov19? 00:00:00 / lib / systemd / systemd-udevd

Stavim, da ste to takoj opazili. prvi postopek v seznamu se je začel kot uporabniški koren in ima pid 1.

Seveda je bil to prvi postopek, ki ga je sistem sprožil ob zagonu. Pozdravi sistemd. ��

Preprosto, systemd je “matični” postopek, ki zažene, upravlja in zaključuje druge procese v sistemu, poleg tega pa zagotavlja informacije o njihovi dnevniki, stanjih datotečnega sistema itd..

Opomba o imenu. Ime je res sistemsko in ni sistem D ali kaj drugega. “D” pomeni daemon, standardni postopek Linuxa, ki deluje (skriva?) V ozadju in ni priključen na nobeno terminalsko sejo..

Zakaj je RHEL prešel na systemd?

Kot smo že razpravljali, je systemd sistemski in procesni upravitelj in v RHEL 7 nadomešča dobro znani program Upstart. Zakaj je RHEL (Oracle?) Sprejel to odločitev? No, za to obstajajo zelo dobri razlogi, zato poglejmo na hitro.

Inicializacija vzporedne storitve

Ne mara SysV init programa, sistemd lahko vzporedno zažene storitve. Nasprotno, program init jih sproži enega za drugim. V času, ko imajo celo mobilne naprave večjedrne procesorje, je pomanjkanje vzporedne inicializacije velik izklop.

Dinamično (vroče) upravljanje storitev

Če ste opazili, da je treba pogone USB izrecno namestiti v prejšnje sisteme Fedora, medtem ko bi se samodejno odprli na Ubuntu in podobnih distribucijah, je razlog v tem. Sposoben je zaznati spremembe v strojni opremi v živo in po potrebi zaključiti / zagnati storitve. Nekateri lahko trdijo, da je nepotrebno, toda mnogim je vse, kar zmanjšuje kognitivno breme, najbolj dobrodošlo.

Odloženi zagon storitve

systemd skrajša čas zagona, saj lahko odloži zagon storitve, ko je dejansko potreben. Preprost primer so storitve, povezane z omrežnim datotečnim sistemom. Če ni na voljo omrežnega diska, ni smiselno, da bi bila storitev zagnana in zagnana.

Hitrejša procesna komunikacija

Vzporedne zmožnosti sistema prenašajo na medprocesno komunikacijo. systemd lahko ponudi vzporeden dostop do vtičnic in sistemskih vodil, kar znatno skrajša čakalne dobe procesa za komunikacijske vire.

Samodejni ponovni zagon

Če se storitev zruši, lahko sistemd to zazna in poskusi znova zagnati. V večini primerov je preprost ponovni zagon vse, kar je potrebno, da aplikacija ponovno začne delovati, razen če ni več temeljnih težav.

Kakor koli, sistemd olajša življenje sysadmin-a tukaj.

sistemd v RHEL7 – Kaj se spreminja za Sysadmins?

Če imate občutek, da sistemd ne bodo vsi zvonovi, ste prav. Nekaj ​​pomembnih nezdružljivosti lahko preseneti RHEL sysadmin. Oglejmo si na hitro.

Omejena podpora za vožnjo

systemd ima precej tresoče prepoznavanje in podporo tekaških ravni. Niso podprte vse vozne ravni in za nekatere cilje jih morda sploh ni. V takšnih primerih systemd vrne „N“ kot odgovor na ukaze vozne ravni, kar pomeni, da za to tarčo nima ustrezne ravni teka. Skupno nam Red Hat svetuje, da ne uporabljamo (!) Ukazov runlevel.

Ukazov po meri ni

To bo škodilo. En velik plus pri SysV-u je bila sposobnost določitve ukazov po meri, da bi zagotovili boljšo funkcionalnost za upravljanje procesov. Pri sistemu systemd takšne možnosti ni in ste obtičali z zagonom, ustavitvijo, statusom, ponovnim zagonom itd.

Samo za družino in ne-interaktivno

systemd (seveda) spremlja procese, ki jih je sprožil, in shranjuje njihove PID. Izziv pa je, da systemd ne more obravnavati procesov, ki jih ta ni sprožil. Poleg tega uporabnik ne more komunicirati s postopkom, ki ga začne sistemd. Ves izhod gre v / dev / null, kar dejansko ustavi vse upe, ki bi jih imeli pri zajemanju izhoda.

Brez konteksta

Za razliko od init storitev, ki jih je sprožil systemd, noben uporabnik v sistemu ne podeduje nobenega okolja. Z drugimi besedami, informacije, kot so PATH in druge spremenljivke sistema, niso na voljo, vsak nov postopek pa se sproži v praznem kontekstu.

Če te seznam omejitev spet zajoka, niste sami. systemd je bila v svetu Linux polarizacijska sila in Googling o “sistemskih zalogah” bo odkril veliko gradiva za branje. ��

Kako samodejno zagnati storitev, ko ste dol?

Tu je precej pogost primer uporabe pri uvajanju. Program moramo demonizirati v jeziku, ki nima dolgotrajnih procesov: PHP! Predpostavimo, da pišem PHP skript za obdelavo dohodnih povezav s spletnimi vtičnicami (navsezadnje smo vgradili aplikacijo za klepet!), Skript pa postavljen na /home/ankush/chat_server/index.php.

Ker internetne povezave lahko kadar koli zadenejo strežnik, mora biti ta postopek ves čas vklopljen in nadzorovati dohodne povezave. Tukaj ne moremo imeti tradicionalnega življenjskega cikla PHP, ker so WebSockets zvezne povezave in če skript umre, je povezava seznam. Kakorkoli že, dovolj na spletnih nogavicah; poglejmo, kako si bomo prizadevali za demoniziranje tega skripta prek systemd.

Vse sistemske storitve prebivajo v / etc / systemd / system, zato ustvarimo datoteko za opis skripta našega spletnega strežnika. Ob predpostavki, da ste prijavljeni kot korenski uporabnik.

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

in potem je potrebno naslednje.

[Enota]
Opis = Storitev strežnika za klepet
Po = network.target

[Storitev]
Vrsta = preprosta
Uporabnik = ankush
ExecStart = php /home/ankush/chat_server/index.php
Ponovni zagon = prekinitev

[Namestitev]
WantedBy = večnamenska tarča

Shranite datoteko in naslednji korak je znova naložiti sistemd demona

# systemctl daemon-reload

in začeti storitev, ki smo jo pravkar ustvarili:

# systemctl zaženite chat_server

Če ne vidite napak, je bilo to!

Oglejmo si tudi, kaj pomenijo različne direktive v datoteki:

  • Del [Unit] določa novo servisno enoto za systemd. V sistemskem govoru so vse storitve znane kot servisne enote.
  • Direktiva After (predvidljivo) sporoča systemd, naj to storitev zažene šele po zagonu omrežnih storitev (drugače, kdo bo izvajal ravnanje s socket povezavami na nižji ravni ?!).
  • Tip = preprost sporoča systemd, da se ta storitev ne bi smela viliti. Z drugimi besedami, v določenem času se bo izvajal samo en primerek.
  • Uporabnik = ankush pomeni, da se bo ta storitev izvajala kot uporabnik “ankush”. To bi lahko spremenili v “root”, vendar je z vidika varnosti to zelo nepriporočljivo.
  • Kot kaže, je ExecStart dejanski ukaz za zagon.
  • Restart = on-abort pomeni, da je treba storitev znova zagnati, ko prekine. V PHP-ju dolgotrajni procesi puščajo spomin in sčasoma eksplodirajo, zato je to potrebno.
  • Direktiva WantedBy = sporoča systemd, katere cilje (pomislite na skupine) je del te storitve. Tako se znotraj tega cilja ustvarijo simbolne povezave, ki kažejo na storitev.

Na splošno je to dovolj za izvajanje procesov v ozadju z uporabo systemd v RHEL 7.

Več možnosti za logiko za zagon

V zgornjem primeru sem konfiguriral Restart = on-abort, vendar to ni edina možnost. Več jih je in izberite glede na zahtevo.

  • ob neuspehu – se znova zažene, ko je nečista izhodna koda ali signal
  • nenehno – znova zaženite, ko najdem signal, čist ali nečist
  • na-nenormalno – nečisti signal, čuvaj ali časovna omejitev
  • uspeh – samo takrat, ko ga je ustavil čisti signal ali izhodna koda

Konfiguriranje storitve za zagon ob zagonu

Ko ste zadovoljni s skriptom in zagotovite, da deluje, potem ga želite nastaviti tako, da se sproži ob zagonu in zažene.

Pojdite na / etc / systemd / system in zaženite spodnji ukaz (ne pozabite spremeniti imena datoteke .service s tistim, ki ga imate)

# systemctl omogočite chat_server.service

Prikazala se bo potrditev, da je ustvarila povezavo.

Ustvarilo je povezavo iz /etc/systemd/system/multi-user.target.wants/chat_server.service v /etc/systemd/system/chat_server.service.

Znova zaženite strežnik in na zagonu bi se morala videti storitev.

To je bilo enostavno! Kajne?

Pomoč! Veliko vlagam v Upstart. ��

Razumem, da mi zaupate, vaš primer je prej norma in ne izjema. RHEL že dolgo uporablja Upstart, da se stikalo skorajda zdi izdaja. Toda hej, sistemi se nenehno spreminjajo in ne bi se smeli prepirati po malenkostih. Red Hat priznava, da se veliko ljudi zatakne pri starejših različicah, in ustvarili so migracijski vodnik na katero bi se vsekakor morali sklicevati.

Ena od prednosti pri vsem tem je, da je sistemd združljiv s SysV init skripti, zato boste morali večinoma preprosto premakniti datoteke in zagnati iste storitve..

Vas zanima, če želite izvedeti več o administraciji in odpravljanju težav Linuxa? Oglejte si to spletni tečaj.

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