Rularea inteligentă a serviciilor Linux include cunoașterea modului de testare a statutului lor, care, la rândul său, necesită înțelegerea modului în care distribuțiile Linux moderne gestionează procesele. Acest articol va explora pe scurt funcția și istoria systemd – managerul de proces care pare a fi iubit, temut și urât în ​​părți egale.

Ceva din cutia dvs. Linux nu rulează? Depanarea este prietenul tău. Dar înainte de a ajunge chiar acolo, nu ar trebui să vă asigurați că serviciul de bază rulează efectiv? Uneori, fișierele de configurare sunt setate implicit la inactive.

Poți să folosești starea systemctl pentru a afla dacă un serviciu – OpenSSH în acest exemplu – rulează pe computerul dvs.:

$ systemctl status ssh
● ssh.service – Server OpenBSD Secure Shell
Încărcat: încărcat (/lib/systemd/system/ssh.service; activat; presetare furnizor: activat)
Activ: activ (rulează) de luni 2017-05-15 12:37:18 UTC; Acum 4h 47min
PID principal: 280 (sshd) <2>
Sarcini: 8
Memorie: 10,1M
CPU: 1.322s
CGroup: /system.slice/ssh.service
├─ 280 / usr / sbin / sshd -D
├─ 894 sshd: ubuntu [priv]
├─ 903 sshd: ubuntu @ pts / 4
├─ 904 -bash
├─1612 bash
├─1628 sudo systemctl status ssh
└─1629 systemctl status ssh
[…]

În acest caz, după cum puteți vedea din linia activă a ieșirii, totul este în regulă. Dacă totuși ar fi trebuit să-l încercați, veți folosi systemctl încă o dată, dar de data aceasta cu start in locul stare. Plictisit de noua ta jucărie? systemctl stop o va pune deoparte pentru tine.

# systemctl stop ssh

Acel tip de sistem pare destul de drăguț, dar abia am avut șansa să-l întâlnim. Să sapăm mult mai adânc.

Managementul proceselor Linux

În primul rând, ce este systemctl și ce face de fapt? Pentru a răspunde corect la această întrebare, va trebui să vă gândiți puțin la modul în care Linux gestionează procesele de sistem în general. Și întrucât este întotdeauna plăcut să cunoașteți noi prieteni, veți afla, de asemenea, despre unele instrumente de urmărire a proceselor pentru a înțelege modul în care lucrurile funcționează mai ușor.

Software-ul, după cum sunt sigur că știți deja, este codul de programare care conține instrucțiuni pentru a controla hardware-ul computerului în numele utilizatorilor umani. Un sistem de operare este un instrument pentru organizarea și gestionarea pachetelor software, astfel încât acestea să poată utiliza în mod eficient resursele hardware ale unui computer. Organizarea și gestionarea proceselor pentru un mediu complex de operare multi-proces și multi-utilizator nu este o sarcină simplă. Pentru ca acesta să funcționeze, veți avea nevoie de un fel de polițist de trafic pentru a controla strâns numeroasele părți în mișcare. Permiteți-mi să vă prezint systemctl, un ofițer harnic în divizia de trafic a Departamentului de Poliție Linux.

O scurta prezentare generala si istoricul systemd managerul de
Disponibilitatea și capacitatea de reacție a multor servicii de sistem sunt gestionate de managerul de proces systemctl al systemd

Vizualizarea proceselor cu comanda ps

Să scoatem un microscop electronic și să vedem dacă nu putem detecta un proces real în habitatul său natural. Primul proces care se trezește și pune în funcțiune orice altceva când pornește un computer Linux se numește init (deși așa cum vom descoperi în curând, acest nume poate fi înșelător). Puteți vedea singur că init este mai întâi executând următoarea comandă ps exact așa cum este tipărită aici – voi explica detaliile în doar un minut.

$ ps -ef | grep init
rădăcină 1 0 0 12:36? 00:00:00 / sbin / init
ubuntu 1406 904 0 16:26 pts / 4 00:00:00 grep –color = auto init

Coloana din dreapta a ieșirii (/ sbin / init pe prima linie) reprezintă locația și numele fișierului din spatele procesului în sine. În acest caz, este un fișier numit „init” care se află în directorul / sbin. Coloana din stânga de pe această primă linie conține cuvântul rădăcină și ne spune că proprietarul acestui proces este utilizatorul root. Singura altă informație care ne interesează acum este numărul 1, care este ID-ul procesului (PID) al procesului inițial. Singurul mod în care vei obține PID 1 este să ajungi acolo înainte ca oricine altcineva.

Apropo, a doua linie afișată de acea comandă ps este procesul atribuit comenzii grep în sine. Rețineți cum proprietarul său este ubuntu (numele meu de utilizator) și PID-ul său este mult mai mare decât 1.

Înainte de a trece mai departe, merită să petreceți puțin mai mult timp cu ps. După cum ați văzut, ps afișează informații despre procesele active. Este adesea important să avem acces la informații legate de proces, astfel încât să putem planifica și depana corect comportamentul sistemului. Vă puteți aștepta să utilizați ps devreme și des.

Dacă ar fi să tastați doar ps și să-l rulați, probabil că veți obține doar două rezultate: primul, un proces numit bash care reprezintă interpretul de comandă Bash utilizat de sesiunea dvs. curentă de shell și cea mai recentă comandă (care, din desigur, a fost ps). Dar, uitându-vă la PID-ul atribuit lui Bash (7447, în acest exemplu), știți doar că există o mulțime și o mulțime de alte procese deja greu de lucru undeva pe sistemul dvs. Acestea vor fi generate de cochilii părinți care se îndreaptă până la procesul inițial în sine.

$ ps
PID TTY TIME CMD
7447 puncte / 3 00:00:00 bash
8041 puncte / 3 00:00:00 ps

Adăugarea argumentului -e la ps așa cum am făcut mai sus va reveni nu numai procesele care rulează în shell-ul dvs. curent copil, ci toate procesele de la toate shell-urile părinte chiar înapoi la init.

Un shell părinte este un mediu shell din care pot fi lansate ulterior shell-uri noi (copil) și prin care rulează programe. Vă puteți gândi la sesiunea desktop GUI ca la un shell și la terminalul pe care îl deschideți pentru a obține o linie de comandă ca fiind copilul său. Învelișul de nivel superior (bunicul?) Este cel care se execută mai întâi când bootează Linux.

Dacă doriți să vizualizați procesele / procesele părintelui și copilului, puteți utiliza pstree comanda (adăugând argumentul -p pentru a afișa numerele PID pentru fiecare proces). Rețineți cum este primul proces (PID 1 atribuit) systemd. Pe versiunile mai vechi de Linux, aceasta ar fi fost numită init in schimb.

$ pstree -p
systemd (1) ─┬─getty (264)
├─getty (266)
├─getty (267)
├─getty (268)
├─getty (269)
├─apache2 (320) ─┬─apache2 (351)
│ ├─apache2 (352)
│ ├─apache2 (353)
│ ├─apache2 (354)
│ └─apache2 (355)
├─cron (118)
├─dbus-daemon (109)
├─dhclient (204)
├─dockerd (236) ─┬─docker-containe (390) ─┬─ {docker-containe} (392)
│ │ └─ {docker-containe} (404)
│ ├─ {dockerd} (306)
│ └─ {dockerd} (409)
├─mysqld (280) ─┬─ {mysqld} (325)
│ ├─ {mysqld} (326)
│ └─ {mysqld} (399)
├─nmbd (294)
├─rsyslogd (116) ─┬─ {în: imklog} (166)
│ ├─ {în: imuxsock} (165)
│ └─ {rs: main Q: Reg} (167)
├─smbd (174) ─┬─smbd (203)
│ └─smbd (313)
├─sshd (239) ───sshd (840) ───sshd (849) ───bash (850) ───pstree (15328)
├─systemd-journal (42)
└─systemd-logind (108)

Continuați și încercați toate aceste comenzi pe propria mașină. Chiar și pe un sistem silențios, veți vedea probabil zeci de procese; un computer desktop sau server ocupat poate avea cu ușurință mii.

Lucrul cu systemd

Există ceva interesant la fișierul / sbin / init pe care tocmai l-am văzut. „Fișier” este un venerabil program Unix care vă oferă informații privilegiate despre un fișier. Dacă alergi fişier cu / sbin / init ca argument, veți vedea că fișierul init nu este de fapt un program, ci pur și simplu o legătură simbolică către un program numit systemd.

$ file / sbin / init
/ sbin / init: link simbolic către / lib / systemd / systemd

După mulți ani de fragmentare și unele lupte politice puternice, aproape toate distribuțiile Linux folosesc acum același manager de proces: systemd. systemd este un înlocuitor pentru procesul inițial. Prin „înlocuire drop-in” vreau să spun că, chiar dacă modul în care realizează lucrurile poate fi destul de diferit, față de observatorul casual, funcțiile systemd la fel cum a făcut întotdeauna init. De aceea, fișierul / sbin / init nu este acum nimic mai mult decât un link către programul systemd.

Acest lucru este un pic teoretic, deoarece probabil că nu veți invoca niciodată programul systemd în sine – fie direct, fie prin front-end-ul său / sbin / init. Acest lucru se datorează faptului că, după cum ați văzut deja, sarcinile de administrare cheie sunt gestionate de systemctl în numele systemd.

Din punct de vedere tehnic, sarcina principală a sistemului este de a controla felul în care se nasc procesele individuale, își trăiesc viața și apoi mor. Comanda systemctl pe care am folosit-o mai sus este instrumentul ales pentru acele sarcini. Dar – oarecum controversat – dezvoltatorii de sistem au extins funcționalitatea mult dincolo de rolul tradițional al gestionării proceselor pentru a prelua controlul asupra diferitelor servicii de sistem. În noua umbrelă systemd sunt incluse instrumente precum un manager de logare (journald), un manager de rețea (networkd) și un manager de dispozitive (ați ghicit: udevd). Curios? „D” înseamnă daemon; un proces de sistem de fundal.

O scurta prezentare generala si istoricul systemd managerul de

Acest articol este adaptat de la capitolul 3 (Conectivitate la distanță: acces în siguranță la mașini conectate în rețea) din my Manning carte „Linux în acțiune”. Există mult mai multă distracție de unde a venit acest lucru – inclusiv Cursuri de administrare Linux și Docker despre Pluralsight și un curs hibrid numit Linux în mișcare este alcătuit din mai mult de două ore de videoclip și aproximativ 40% din textul Linux în acțiune. Cine știe … s-ar putea să te bucuri și tu celelalte cărți și cursuri ale mele.