Cum să porniți automat serviciile pe Boot în RHEL / CentOS 7?

Vă întrebați cum să gestionați serviciile în fundal sau pe boot?


Mecanismul de gestionare și pornire a proceselor la boot a fost schimbat. Până la RHEL / CentOS 6.x, ai fi creat un script în /etc/init.d/ și activat cu ajutorul chkconfig, dar lucrurile sunt diferite pe RHEL 7.

Este înlocuit de systemd și, deoarece este mai mult sau mai puțin managerul de proces implicit pentru versiunile Linux majore, System Admin versat în alte arome se va simți ca acasă. În acest articol, vom explora care este systemd, care au fost motivele pentru comutator și cum să utilizați systemd pentru a configura, rula și gestiona procesele de fundal cu acesta.

Ce este systemd?

Întrucât fiecare proces în Linux este vizibil în mod transparent, să vedem unde se află pământul sistemului. Pe sistemul meu, primesc următoarele:

~ $ ps -ef | grep systemd
rădăcină 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd –system –deserialize 22
mesaj + 768 1 0 Nov11? 00:05:46 / usr / bin / dbus-daemon –system –address = systemd: –nofork –nopidfile –systemd-activation – onlyslog
rădăcină 805 1 0 Nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 Nov11? 00:00:00 / lib / systemd / systemd – utilizator
ankush 1176 1132 0 Nov11? 00:04:50 / usr / bin / dbus-daemon –session –address = systemd: –nofork –nopidfile –systemd-activation – onlyslog
ankush 9772 20029 0 21:11 pts / 6 00:00:00 grep –color = sistem auto
sistemd + 17298 1 0 Nov19? 00:00:12 / lib / systemd / systemd-rezolvată
sistemd + 17303 1 0 Nov19? 00:00:00 / lib / systemd / systemd-timesyncd
rădăcină 17307 1 0 Nov19? 00:00:02 / lib / systemd / systemd-journald
rădăcină 18182 1 0 Nov19? 00:00:00 / lib / systemd / systemd-udevd

Pariez că ai observat-o instantaneu. primul proces din listă a fost lansat ca rădăcină de utilizator și are pid 1.

Destul de sigur, acesta a fost primul proces pe care sistemul l-a lansat la pornire. Spuneți-vă salut sistemului. ��

Așadar, destul de simplu, systemd este procesul „mamă” care lansează, gestionează și încheie alte procese din sistem, pe lângă furnizarea informațiilor despre logarea lor, stările sistemului de fișiere etc..

O notă despre nume, totuși. Numele este într-adevăr systemd și nu System D sau altceva. „D” înseamnă demon, un proces Linux standard care funcționează (ascunde?) În fundal și nu este atașat la nicio sesiune de terminal..

De ce RHEL a trecut la systemd?

După cum am discutat deja, systemd este un manager de sistem și proces, iar în RHEL 7, înlocuiește binecunoscutul program Upstart. De ce a luat această decizie RHEL (Oracle?)? Ei bine, există motive foarte bune pentru asta, deci aruncăm o privire rapidă.

Inițializarea serviciului paralel

Nu-i place programul SysV init, systemd este capabil să lanseze servicii în paralel. Programul init, în schimb, le lansează unul câte unul. Într-o epocă în care chiar și dispozitivele mobile au CPU multi-core, lipsa inițializării paralele este o mare dezactivare.

Managementul serviciilor dinamice (la cald)

Dacă ați observat că unitățile USB trebuie montate explicit pe sistemele Fedora anterioare, în timp ce acestea vor deschide automat pe Ubuntu și distribuții similare, motivul este sistem. Este capabil să detecteze modificările live ale hardware-ului și să încheie / lanseze serviciile, după cum este necesar. Unii pot susține că este inutil, dar pentru mulți, orice lucru care reduce povara cognitivă este cel mai binevenit.

Lansare de serviciu amânată

systemd reduce timpii de pornire, deoarece poate amâna lansarea serviciilor la momentul în care este nevoie efectiv. Un exemplu simplu sunt serviciile legate de sistemul de fișiere de rețea. Dacă nu există un disc în rețea disponibil, nu are sens să aveți un serviciu în funcțiune.

Comunicarea mai rapidă a proceselor

Capabilitățile paralele ale sistemului systemd duc la comunicarea dintre procese. systemd este capabil să ofere acces paralel la prize și magistrală de sistem, reducând semnificativ timpul de așteptare al procesului pentru resursele de comunicare.

Reporniți automat

Dacă un serviciu se prăbușește, systemd poate detecta și încerca să-l reporni. De cele mai multe ori, o simplă repornire este tot ceea ce este necesar pentru ca o aplicație să înceapă să funcționeze din nou, dacă nu există probleme mai fundamentale.

În orice caz, systemd face viața unui sysadmin mai ușor aici.

systemd în RHEL7 – Ce se schimbă pentru Sysadmins?

Dacă ai impresia că sistemul nu va fi doar clopot, fluier, ai dreptate. Există câteva incompatibilități semnificative care pot surprinde RHEL sysadmin prin surprindere. Să aruncăm o privire rapidă.

Asistență limitată la nivel de rulare

systemd are o recunoaștere destul de neplăcută și suport pentru runlevels. Nu toate nivelurile de execuție sunt acceptate, iar pentru unele ținte ar putea fi chiar unul. În astfel de cazuri, systemd returnează „N” ca răspuns la comenzile runlevel, ceea ce înseamnă că nu are un nivel de execuție corespunzător la această țintă. În total, Red Hat ne sfătuiește să nu folosim (!) Comenzile runlevel.

Nu există comenzi personalizate

Acesta o să doară. Un mare plus cu SysV a fost capacitatea de a defini comenzi personalizate pentru a oferi o funcționalitate mai bună pentru gestionarea proceselor. Cu sistemd, nu există o astfel de opțiune și sunteți blocat cu pornirea, oprirea, starea, repornirea etc..

Numai pentru familie și non-interactiv

systemd (desigur) ține o evidență a proceselor lansate și stochează PID-urile lor. Provocarea este însă că sistemd nu poate face față proceselor care nu sunt lansate de acesta. Mai mult, nu este posibil ca un utilizator să interacționeze cu un proces început de systemd. Toată ieșirea se duce la / dev / nul, punând efectiv capăt oricărei speranțe pe care le-ați putea avea de captat.

Fără context

Spre deosebire de serviciile init, cele lansate de systemd nu moștenesc niciun mediu de la niciun utilizator din sistem. Cu alte cuvinte, informații precum PATH și alte variabile de sistem nu sunt disponibile și fiecare nou proces este lansat într-un context gol.

Dacă această listă de limitări te face să plângi, din nou, nu ești singur. systemd a fost o forță polarizantă în lumea Linux, iar Googling pe „systemd sucks” va descoperi o mulțime de materiale de citire. ��

Cum să porniți serviciul automat când este în jos?

Iată un caz de utilizare destul de comun în implementări. Trebuie să demonizăm un program într-un limbaj care nu are procese de lungă durată: PHP! Să presupunem că scriu un script PHP pentru a gestiona conexiunile de conectare la intrare (am construit o aplicație de chat, până la urmă!), Iar scriptul este plasat la /home/ankush/chat_server/index.php.

Deoarece conexiunile websocket pot atinge serverul în orice moment, acest proces trebuie să fie în permanență activ și să monitorizeze conexiunile primite. Nu putem avea ciclul de viață PHP tradițional aici, deoarece WebSockets sunt conexiuni statale, iar dacă scriptul moare, conexiunea este o listă. Oricum, suficient pe websockets; să vedem cum vom merge despre demonizarea acestui script prin sistem.

Toate serviciile systemd se află în / etc / systemd / system, deci creăm un fișier acolo pentru a descrie scriptul serverului nostru de la websocket. Presupunând că sunteți autentificat ca utilizator root.

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

și atunci este nevoie de următoarele.

[Unitate]
Descriere = Chat Server Service
După = network.target

[Serviciu]
Tip = simplu
Utilizator = ankush
ExecStart = php /home/ankush/chat_server/index.php
Restart = on-abort

[Instalare]
WantedBy = multi-user.target

Salvați fișierul și următorul pas este să reîncărcați demonul de sistem

# systemctl daemon-reload

și pentru a porni serviciul pe care tocmai l-am creat:

# systemctl start chat_server

Dacă nu vezi nicio eroare, asta a fost!

Să aruncăm rapid o privire și la ce înseamnă diversele directive din dosar:

  • Partea [Unit] definește o nouă unitate de service pentru sistemd. În limbajul de sistem, toate serviciile sunt cunoscute sub numele de unități de servicii.
  • Directiva After (previzibil) îi spune lui systemd să lanseze acest serviciu numai după lansarea serviciilor de rețea (altfel, cine va face gestionarea la nivel inferior a conexiunilor socket ?!).
  • Tipul = simplu indică systemd că acest serviciu nu trebuie să se încurce singur. Cu alte cuvinte, o singură instanță va rula orice timp.
  • User = ankush înseamnă că acest serviciu va funcționa ca utilizator „ankush”. Am putea schimba acest lucru în „rădăcină”, dar nu este foarte recomandat din perspectiva securității.
  • ExecStart, după cum vă puteți spune, este comanda reală de rulat.
  • Restart = on-abort înseamnă că serviciul ar trebui să fie repornit atunci când se avizează. În PHP, procesele pe termen lung scurg memoria și în cele din urmă explodează, astfel încât acest lucru este necesar.
  • Directiva WantedBy = spune systemd din care țintă (gândiți-vă la grupuri) din care face parte acest serviciu. Acest lucru duce la crearea de legături simbolice în interiorul acestei ținte pentru a indica serviciul.

În general, acest lucru este suficient pentru a rula procesele de fundal folosind systemd în RHEL 7.

Mai multe opțiuni pentru Restart logica

În exemplul de mai sus, am configurat Restart = on-abort, dar aceasta nu este singura opțiune. Există mai multe și alegeți pe baza cerinței.

  • on-eșec – va fi repornit atunci când codul sau semnalul de ieșire necurat
  • mereu – reporniți când este găsit, semnal curat sau necurat
  • on-anormale – semnal necurat, pază de veghe sau expirare
  • on-succes – numai atunci când a fost oprit de un semnal curat sau un cod de ieșire

Configurarea serviciului pentru a porni la pornire

După ce vă mulțumiți cu scriptul și vă asigurați că acesta funcționează, în continuare doriți să configurați astfel încât să se declanșeze la pornire și să porniți.

Accesați / etc / systemd / system și executați mai jos comanda activare (nu uitați să modificați numele fișierului .service cu cel pe care îl aveți)

# systemctl activează chat_server.service

Veți vedea o confirmare că a creat un simbol.

Simbol link creat de la /etc/systemd/system/multi-user.target.wants/chat_server.service la /etc/systemd/system/chat_server.service.

Reporniți serverul și ar trebui să vedeți că serviciul începe la pornire.

A fost ușor! Nu-i așa?

Ajutor! Am investit masiv în Upstart. ��

Înțeleg că ai încredere în mine, cazul tău este norma și nu excepția. RHEL folosește Upstart de mult timp încât comutatorul se simte aproape ca o trădare. Dar hei, sistemele continuă să se schimbe și nu ar trebui să ne aruncăm peste fleacuri. Red Hat recunoaște că multe persoane sunt blocate cu versiuni mai vechi și au creat un ghid de migrare la care ar trebui să vă referiți cu siguranță.

Un har salvator în toate acestea este faptul că systemd este compatibil cu scripturile initiale SysV, astfel încât, în cea mai mare parte, va trebui pur și simplu să vă mutați fișierele și să executați aceleași servicii..

Vrei să afli mai multe despre administrarea Linux și soluționarea problemelor? Verifica asta curs online.

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