Aplicarea practică a cunoștințelor despre subsistemul rc.d. primit de la documentația oficială a BSD nu este întotdeauna o problemă simplă pentru un începător. În acest articol, vom examina câteva versiuni tipice de script-uri de pornire, vă vom arăta cum să folosiți funcțiile rc.d în fiecare dintre aceste cazuri și să discutați cum funcționează. Această examinare vă va oferi o prezentare despre subsistemul rc.d pentru o dezvoltare eficientă ulterioară.
Odată ce BSD avea un script de pornire monolit / etc / rc. Acesta a fost numit de init (8) la momentul încărcării sistemului, iar acest script a executat toate sarcinile din spațiul utilizator necesar pentru operațiile cu mai mulți utilizatori: verificarea și montarea sistemelor de fișiere, configurarea rețelei, pornirea daemonilor și altele asemenea. Dar lista acestor sarcini nu este aceeași în diferite sisteme, administratorii au nevoie de mai multă atenție. Cu excepția anumitor momente, / etc / rc a fost ușor accesibil la modificări, iar oamenii cu adevărat entuziasmați și cu plăcere au modificat-o.
Principala problemă cu această soluție monolită a fost că nu a furnizat un mecanism de control al componentelor individuale care au fost executate din scriptul / etc / rc. De exemplu, / etc / rc nu a putut reporni un serviciu separat. Administratorul de sistem a trebuit să găsească manual identificatorul procesului, să omoare acest proces, să aștepte finalizarea procesului, să găsească parametrii din fișierul / etc / rc cu care a început acest proces, să pornească manual procesul de la linia de comandă. Această secvență de operații a devenit chiar mai confuză și mai complexă dacă serviciul reînceput a dat naștere la mai multe procese sau a solicitat acțiuni suplimentare la pornire. Pe scurt, un script de pornire monolit nu a putut efectua sarcina de bază a tuturor scripturilor - făcând viața administratorului de sistem mai ușoară.
Mai târziu, s-au făcut încercări de a împărți / etc / rc în părți, cu scopul de a face unele dintre cele mai importante elemente. Un exemplu frumos este scriptul / etc / netstart. care inițializează rețeaua. Acest script a permis să pornească rețeaua din modul de utilizator unic, dar era imposibil să se integreze pe deplin în sistemul autorun, deoarece părți ale codului aferente rețelei trebuiau să fie intercalate cu părți care nu aparțineau rețelei. Din acest motiv, scriptul / etc / netstart a fost mutat în timp în /etc/rc.network. Acesta din urmă nu mai este un script complet independent, constă în funcții mari, interdependente scrise în sh (1). care, la rândul lor, sunt chemați de la / etc / rc în diferite stadii de pornire a sistemului. Între timp, deoarece scripturile de pornire au devenit mai mari, au apărut dependențe complexe între ele, un sistem de lansare "cvasi-modular" a devenit și mai confuz decât scriptul monolit / etc / rc.
Fără un subsistem simplu și transparent, scripturile de start au devenit și mai puțin satisfăcătoare nevoilor sistemelor BSD care se dezvoltă rapid. A devenit evident că sunt necesare pași fundamentali pentru a atinge modularitatea și flexibilitatea sistemului de lansare rc. Pe baza acestor considerente, sistemul de lansare BSD rc.d a fost creat. Părinții ei recunoscuți au fost Luke Mewburn (Luke Mewburn) și comunitatea NetBSD. Mai târziu, acest sistem a fost importat în FreeBSD. Numele său se referă la localizarea scripturilor de sistem pentru servicii individuale, care se află în /etc/rc.d. Puțin mai târziu vom examina componentele individuale ale sistemului rc.d și vom vedea cum rulează scripturile individuale.
Ideea generală din spatele sistemului de pornire BSD rc.d este un grad ridicat de modularitate și reutilizare a codului. Un grad ridicat de modularitate înseamnă că fiecare "serviciu" separat, cum ar fi un daemon de sistem sau cea mai simplă sarcină, utilizează propriul scenariu scris în sh (1). care poate porni, opri, reporni serviciul și verifică starea acestuia. Acțiunea standard este selectată din linia de comandă a scriptului. / etc / rc este, ca și înainte, scriptul principal de boot, dar acum nu execută întregul proces de boot, ci solicită script-uri separate cu parametrul de pornire. De asemenea, este ușor să opriți sistemul - acesta este pornit de același set de scripturi, dar cu un argument de oprire. Această acțiune este efectuată de scriptul de control /etc/rc.shutdown. Rețineți cât de precis acest sistem de lansare este compatibil cu principiul tradițional Unix de a utiliza un set de instrumente de specialitate mici, fiecare dintre acestea fiind conceput pentru a rezolva o anumită sarcină. Reutilizarea de cod este o abordare care înseamnă că operațiile utilizate frecvent sunt implementate ca funcții în limba sh (1) și sunt combinate în fișierul / etc / rc.subr. Acum, un script tipic poate consta doar din câteva linii de cod în sh (1). În cele din urmă, o parte foarte importantă a subsistemului rc.d este programul rcorder (8). care ajută scriptul / etc / rc să ruleze scripturi individuale într-o anumită ordine, ținând cont de dependențele dintre ele. În special, ajută și scriptul /etc/rc.shutdown. Deoarece ordinea corectă de oprire a sistemului este opusul ordinului la pornire.
Există mai multe cerințe pentru o înțelegere completă a materialului prezentat. Mai întâi, ar trebui să fiți familiarizați cu programarea în limba script (sh) (1). În al doilea rând, trebuie să înțelegeți modul în care sistemul execută acțiunile de pornire și de sfârșit ale spațiului utilizatorului, descrise în rc (8).
O notă mică înainte de început. Nu vă fie teamă de variabila de mediu $ EDITOR.
Pentru a scrie scripturi de calitate rc.d pentru serviciile de sistem, trebuie să răspundem la următoarele întrebări:
Este acest serviciu obligatoriu sau nu?
Scenariul va servi doar un program (adică un daemon) sau va îndeplini sarcini mai complexe?
Articole similare
Trimiteți-le prietenilor: