Systemctl-poistopalvelu. Ajetaan alkuperäisiä systemd-skriptejä. Palvelun tilan tarkistaminen

Systemd Unit on komentosarja, joka suorittaa erilaisia ​​toimintoja (mitä tahansa kirjoitat siihen). Yleensä kirjoitan tällaisia ​​skriptejä käynnistääkseni erilaisia ​​palveluita, jotka käännetään käsin tai kun käytän valmiita ohjelmistoja.

Mitä Systemd-yksiköt tarjoavat sinulle?

Yksiköt ovat objekteja, joita järjestelmä voi hallita (Periaatteessa standardisoitu esitys järjestelmäresursseista, joita voi hallita joukko demoneja).

Yksiköitä voidaan tietyssä mielessä kutsua palveluiksi tai töiksi, mutta yksiköllä on paljon laajempi määritelmä, koska sitä voidaan käyttää abstrakteihin palveluihin, verkkoresursseihin, laitteisiin, tiedostojärjestelmäliitäntöihin ja eristettyihin resurssivarastoihin.

Jotkut ominaisuudet, jotka on helppo ottaa käyttöön:

• Pistorasiapohjainen aktivointi: Palveluun liittyvät pistokkeet on parasta poimia itse demonista ja käsitellä niitä erikseen. Tällä on useita etuja, kuten palvelun alkamisen viivästyminen, kunnes sopiva pistorasia on käytettävissä. Sen avulla järjestelmä voi myös luoda kaikki socketit ennen prosessin alkamista, mikä mahdollistaa siihen liittyvien palveluiden lataamisen rinnakkain.
• Väyläpohjainen aktivointi: Yksiköt voidaan aktivoida myös D-Busin tarjoamasta väyläliitännästä. Laite voidaan käynnistää, kun vastaava väylä on käytettävissä.
• Polkupohjainen aktivointi: Yksikkö voidaan käynnistää toiminnan tai tiettyjen tiedostojärjestelmäpolkujen olemassaolon perusteella. Se käyttää inotifyta.
• Laitepohjainen aktivointi: Yksiköt voidaan käynnistää myös, kun niihin liittyvä laitteisto on ensimmäisen kerran saatavilla (yhdistetty) käyttämällä udev-tapahtumia.
• Implisiittinen riippuvuuskartoitus: Suurin osa yksiköiden riippuvuusrakenteesta voidaan rakentaa itse järjestelmällä. Voit silti lisätä riippuvuustietoja, mutta suurin osa kovasta työstä tehdään puolestasi.
• Esiintymät ja mallit: Mallilohkotiedostoja voidaan käyttää useiden esiintymien luomiseen samasta yleisestä laitteesta. Näin voit luoda pieniä muunnelmia tai yksittäisiä yksiköitä, jotka tarjoavat saman yleisen toiminnon.
• Yksinkertainen turvallisuuden yksinkertaistus: Yksiköt voivat toteuttaa melko hyviä turvaominaisuuksia lisäämällä yksinkertaisia ​​​​käskyjä. Voit esimerkiksi määrittää, mitä käyttöoikeuksia voidaan käyttää (luku-, kirjoitus-) työskennellessäsi tiedostojärjestelmän kanssa, rajoittaa ytimen ominaisuuksia, asettaa yksityisen /tmp-kansion ja verkkoyhteyden.
• Drop-init ja katkelmat: Yksiköitä voidaan helposti laajentaa tarjoamalla katkelmia, jotka ohittavat osia järjestelmätiedostosta. Tämän ansiosta on helppo vaihtaa vanilja- ja mukautetun toteutuksen välillä.

Järjestelmäyksiköillä on monia muita etuja muiden järjestelmien työosiin verrattuna, mutta tämän pitäisi antaa sinulle käsitys tehosta, joka voidaan valjastaa omilla konfigurointiohjeillasi.

Kuinka löydän / missä ovat järjestelmäyksiköt Unixissa/Linuxissa?

Tiedostot, jotka määrittävät kuinka systemd käsittelee yksikköä, löytyy eri paikoista, jokaisella on eri prioriteetit ja merkitykset.

Kaikki kopiot järjestelmän järjestelmätiedostoista (tarkoitan kaikkia yksiköitä) löytyvät hakemistosta /lib/systemd/system. Tänne tallennetut tiedostot voidaan käynnistää ja pysäyttää pyynnöstä, mutta istunnon aikana. Tämä on yleinen vaniljayksikkötiedosto, jonka kirjoittavat usein kolmannen osapuolen projektikehittäjät, joiden pitäisi toimia missä tahansa järjestelmässä, joka ottaa käyttöön systemd sen vakiototeutuksessa. Et saa muokata tämän hakemiston tiedostoja. Sen sijaan sinun on ohitettava tiedosto (tarvittaessa) toisella tiedoston sijainnilla, joka korvaa tiedoston kyseisessä paikassa.

Jos haluat muuttaa tietyn laitteen toimintaa, sinun on siirryttävä /etc/systemd/system-hakemistoon, koska - tästä hakemistosta löytyvät tiedostot ovat etusijalla muihin tiedostojärjestelmän paikkoihin nähden.

Jos haluat ohittaa vain tietyt käskyt järjestelmäyksikkötiedostoista, voit itse asiassa tarjota yksikkötiedostojen fragmentteja alihakemistossa. Ne lisäävät tai muuttavat ohjeita järjestelmän kopioihin, jolloin voit määrittää vain ne asetukset, joita haluat muuttaa.

Oikea tapa tehdä tämä on luoda tiedoston mukaan nimetty hakemisto, jonka loppuun on liitetty ".d". Siksi yksikölle, jonka nimi on oma_testi.palvelu, tulisi luoda alihakemisto oma_testi.palvelu.d. Tässä hakemistossa .conf-päätteistä tiedostoa voidaan käyttää yksikkötiedoston määritteiden ohittamiseen tai laajentamiseen.

Tiedostossa /run/systemd/system on myös paikka määrittää ajonaikaiset yksiköt. Tästä hakemistosta löytyvät tiedostot ovat etusijalla /etc/systemd/system ja /lib/systemd/system välillä.

Tässä sijainnissa oleville tiedostoille on annettu alhaisempi prioriteetti kuin edelliselle sijainnille, mutta korkeampi kuin edelliselle. Itse systemd-prosessi käyttää tätä sijaintia dynaamisesti luoduille yksikkötiedostoille, jotka on luotu ajon aikana. Tämän hakemiston avulla voidaan muuttaa järjestelmän laitekäyttäytymistä koko istunnon ajan. Kaikki tähän hakemistoon tehdyt muutokset menetetään, kun palvelin käynnistetään uudelleen.

Järjestelmän yksikkötiedostotyypit

Helpoin tapa määrittää laitetyyppi on tarkastella sen päätettä, joka lisätään resurssin (yksikön) nimen loppuun. Seuraavassa luettelossa kuvataan systemd:n ​​käytettävissä olevat yksiköt:

• .palvelu: Tämä yksikkö kuvaa palvelun tai sovelluksen hallinnan palvelimella. Se sisältää palvelun käynnistämisen tai pysäyttämisen, missä olosuhteissa sen pitäisi käynnistyä automaattisesti, sekä vastaavan ohjelmiston riippuvuustiedot.
• .pistoke: Socket-laitetiedosto kuvaa verkkoa, IPC-liitäntää tai FIFO-puskuria, jota systemd käyttää pistokkeen aktivoimiseen. Heillä on aina liitetty .service-tiedosto, joka käynnistetään tämän lohkon määrittävässä socket-toiminnossa.
• .laite: Yksikkö, joka kuvaa laitetta, joka on määritetty ohjaamaan systemd:tä udev- tai sysfs-tiedostojärjestelmällä. Kaikissa laitteissa ei ole .device-tiedostoja. Jotkut komentosarjat, jotka saattavat tarvita devices.device-tiedoston, on tarkoitettu laitteiden asentamiseen ja käyttämiseen.
• .mount: Tämä lohko määrittää järjestelmän liitoskohdan, jota systemd hallitsee. Ne on nimetty asennuspolun mukaan, ja "/" on muutettu viivaksi. Tiedoston /etc/fstab merkinnöissä voi olla automaattisesti luotuja lohkoja.
• .automount: .automount-moduuli määrittää kiinnityspisteen, joka asetetaan automaattisesti ja joka on määritettävä sen liitoskohdan jälkeen, johon ne viittaavat, ja siinä on oltava vastaava .mount-moduuli tiettyjen kiinnitysten määrittämiseksi.
• .vaihtaa: Tämä yksikkö kuvaa SWAP-tilaa (swap space) järjestelmässä. Näiden lohkojen nimen tulee kuvastaa polkua laitteeseen tai tiedostoon.
• .kohde: Tätä yksikköä käytetään synkronointipisteiden tarjoamiseen muille laitteille käynnistettäessä tai vaihdettaessa tilaa. Niitä voidaan käyttää myös järjestelmän saattamiseksi uuteen tilaan.
• .polku: Tämä yksikkö määrittää polun, jota voidaan käyttää polkupohjaiseen aktivointiin. Oletuksena yksikkö käynnistetään samalla perusnimellä. Tämä käyttää inotify-toimintoa polun muutosten seuraamiseen.
• .ajastin: Tämä yksikkö määrittää ajastimen, jota systemd hallitsee (samanlainen kuin cron-työ) viivästettyä tai ajoitettua aktivointia varten. Kun ajastin saavutetaan, vastaava lohko käynnistyy.
• .snapshot: Tämä yksikkö luodaan automaattisesti snapshot systemctl -komennolla. Sen avulla voit palauttaa järjestelmän nykyisen tilan muutosten tekemisen jälkeen. Tilannekuvia ei tallenneta istuntojen välillä, ja niitä käytetään ohimenevien tilojen palauttamiseen.
• .viipale: Se liittyy Linuxin ohjausryhmäsolmuihin, mikä mahdollistaa resurssien rajoittamisen tai niiden kohdistamisen mille tahansa slice-saliin liittyville prosesseille. Nimi kuvastaa sen hierarkkista sijaintia ryhmäpuussa. Yksiköt sijoitetaan oletuksena tiettyihin siivuihin niiden tyypistä riippuen.
• .scope: Systemd luo nämä automaattisesti väyläliittymästään saamistaan ​​tiedoista. Niitä käytetään ulkoisesti luotujen järjestelmäprosessien hallintaan.

Kuten näet, järjestelmä on vuorovaikutuksessa monien eri yksiköiden kanssa. Monet niistä toimivat yhdessä lisätäkseen toimintoja. Useimmiten .servicea käytetään niiden hyödyllisyyden vuoksi.

Systemd-yksikkötiedostojen rakenne

Tiedostojen sisäinen rakenne on järjestetty osioiden avulla. Osat on merkitty kahdella hakasulkeella "[" ja "]", joiden sisällä on osion nimi. Jokainen osa jatkaa seuraavan osan alkuun tai tiedoston loppuun.

Osion nimet ovat hyvin määriteltyjä ja kirjainkoolla on merkitystä. Siten osaa ei tulkita oikein, jos se kirjoitetaan muodossa . Jos sinun on lisättävä ei-standardiosioita jäsentämistä varten (muita kuin systemd), voit lisätä X-etuliite osion nimeen.

Näissä osioissa laitteen käyttäytyminen ja metatiedot määritellään yksinkertaisilla direktiiveillä käyttämällä avainarvomuotoa yhtäläisyysmerkkimäärityksellä, esimerkiksi:

Direktiivi1=arvo Direktiivi2=arvo .......

Jos tiedosto määritellään uudelleen (esimerkiksi hakemistossa unit.type.d), käskyt voidaan nollata antamalla tyhjä merkkijono. Esimerkiksi yksittäisen järjestelmätiedoston kopio voi sisältää seuraavanlaisen määritelmän:

Direktiivi1=oletusarvo

Oletusarvo voidaan jättää pois ohitustiedostosta määrittämällä direktiivi1 (ei arvoa), näin:

Direktiivi1=

Katsotaan nyt jokaista yksikköä erikseen.

Ensimmäinen osio, joka löytyy useimmista yksikkötiedostoista, on . Sitä käytetään tavallisesti laitteen metatietojen määrittämiseen ja laitteen suhteiden määrittämiseen muihin laitteisiin.

Vaikka osioiden järjestyksellä ei ole väliä systemdille tiedostoa jäsennettäessä, tämä osio sijoitetaan usein yläpuolelle, koska se tarjoaa yleiskuvan laitteesta. Joitakin yleisiä ohjeita löydät osiosta:

• Kuvaus =: Tällä ohjeella voidaan kuvata laitteen nimi ja perustoiminnot. Eri järjestelmätyökalut palauttavat sen, joten on hyvä asettaa jotain lyhyttä, tarkkaa ja informatiivista.
• dokumentaatio =: Tämä direktiivi tarjoaa asiakirjojen sijainnit. Nämä voivat olla sisäisiä saatavilla olevia ohjesivuja tai saatavilla Internetissä (URL-osoitteet). "Status system your_service" -komento näyttää nämä tiedot.
• Vaatii =: Tämä ohje luettelee kaikki yksiköt, joista tämä laite (palvelu tai laite) riippuu. Jos nykyinen lohko on aktivoitu, myös tässä lueteltujen yksiköiden on aktivoitu onnistuneesti, muuten se epäonnistuu. Nämä lohkot toimivat rinnakkain nykyisen oletuslaitteen kanssa.
• Haluaa =: Tämä direktiivi on samanlainen kuin Requires=, mutta vähemmän rajoittava. Systemd yrittää käynnistää minkä tahansa tässä luetelluista yksiköistä, kun tämä laite on käytössä. Jos näitä laitteita ei havaita tai käynnistetä, nykyinen lohko jatkaa toimintaansa. Tämä on suositeltu tapa määrittää useimmat riippuvuudet. Tämä taas tarkoittaa rinnakkaista aktivointia, ellei sitä muuteta muilla direktiiveillä.
• BindsTo=: Tämä direktiivi on samanlainen kuin Requires=, mutta aiheuttaa myös nykyisen laitteen pysähtymisen, kun vastaava solmu lopettaa.
• ennen =: Tässä ohjeessa luetellut yksiköt eivät käynnisty ennen kuin nykyinen lohko on merkitty käynnissä olevaksi, jos ne aktivoidaan samanaikaisesti.
• Jälkeen =: Tässä direktiivissä luetellut yksiköt käynnistetään ennen kuin nykyinen laite (yksikkö) käynnistetään.
• Konfliktit =: Tätä yksikköä voidaan käyttää näyttämään yksiköitä, joita ei voida käyttää samanaikaisesti nykyisen laitteen kanssa. Laitteen käynnistäminen tällä yhteydellä saa muut laitteet pysähtymään.
• Kunto…=: On olemassa useita direktiivejä, jotka alkavat ehdolla ja joiden avulla järjestelmänvalvoja voi testata tiettyjä ehtoja ennen laitteen käynnistämistä. Tätä voidaan käyttää luomaan yleinen elementtitiedosto, joka toimii vain kelvollisissa järjestelmissä. Jos ehto ei täyty, yksikkö ohitetaan.
• Väitä…=: Samanlainen kuin yllä oleva ohje (Ehto…=), mutta asetetut direktiivit tarkastavat käyttöympäristön eri puolia päättääkseen, pitäisikö laite aktivoida. Toisin kuin Condition…=-direktiiveissä, negatiivinen tulos aiheuttaa epäonnistumisen tässä direktiivissä.

Näiden ja muutamien muiden ohjeiden avulla voit määrittää yleisiä tietoja laitteesta ja sen suhteesta käyttöjärjestelmään.

Aivan tiedoston lopussa, joka sijaitsee - osiossa. Tämä osio on valinnainen ja sitä käytetään määrittämään käyttäytyminen tai yksikkö, jos se on käytössä tai pois käytöstä. Laitteen käynnistäminen tarkoittaa, että se käynnistyy automaattisesti käynnistyksen yhteydessä. Periaatteessa tämä saavutetaan kiinnittämällä kyseinen laite toiseen lohkoon, joka on jossain käynnistyksen yhteydessä käynnistettävän yksikön rivissä.

Tästä syystä vain yksiköissä, jotka voidaan ottaa käyttöön, on tämä osio. Sisällä olevat ohjeet sanovat, mitä pitäisi tapahtua, kun laite käynnistetään:

• WantedBy=: Tämä direktiivi on yleisin tapa määrittää, kuinka laite tulee käynnistää. Tämän käskyn avulla voit määrittää riippuvuuden (samanlainen kuin Wants=-direktiivi osiossa). Erona on, että tämä direktiivi sisältyy apuyksikköön, jolloin ensiölohko pysyy suhteellisen puhtaana. Kun laite määritetään tällä käskyllä, järjestelmään luodaan kansio /etc/systemd/, joka on nimetty määritetyn laitteen mukaan, mutta jonka lopussa on ".wants". Tässä tapauksessa luodaan symbolinen linkki nykyiseen lohkoon, joka luo riippuvuuden. Esimerkiksi jos nykyisessä lohkossa on WantedBy = multi-user.target, hakemistoon multi-user.target.wants luodaan /etc/systemd/system (jos se ei ole jo saatavilla) ja symbolinen linkki nykyiseen lohkoon. sijoitetaan sisälle. Tämän laitteen poistaminen käytöstä poistaa yhteyden ja riippuvuuden.
• RequiredBy=: Tämä direktiivi on hyvin samanlainen kuin WantedBy=-direktiivi, mutta sen sijaan määrittää vaaditun riippuvuuden, joka aiheuttaa aktivoinnin epäonnistumisen, jos sitä ei täyty. Kun tämä asetus on käytössä, yksikkö, jolla on tämä ohje, luo hakemiston, joka päättyy .requires.
• Alias ​​=: Tämän ohjeen avulla voit ottaa laitteen käyttöön eri nimellä. Muiden käyttötarkoitusten ohella tämä mahdollistaa usean palveluntarjoajan ominaisuudet, jotta vastaavat osastot voivat etsiä minkä tahansa palveluntarjoajan, jolla on yhteinen alias.
• myös =: Tämän ohjeen avulla voit ottaa lohkot käyttöön tai poistaa ne käytöstä joukkona. Täällä voit määrittää tukilaitteet, joiden pitäisi olla aina käytettävissä, kun tämä laite on aktiivinen. Heitä johdetaan ryhmänä asennustehtäviä varten.
• DefaultInstance=: Malliyksiköille (myöhemmin), jotka voivat muodostaa lohkoja arvaamattomilla nimillä, tätä voidaan käyttää nimen varajäsenenä, jos sopivaa nimeä ei ole annettu.

Osaa käytetään tarjoamaan konfiguraatio, joka koskee vain palveluita. Yksi tärkeimmistä osiossa määritellyistä asioista on Type=-palvelu. Se luokittelee palvelut niiden prosessin ja demonisoivan käyttäytymisen perusteella. Tämä on tärkeää, koska se kertoo järjestelmälle, kuinka palvelua tulee hallita oikein ja tietää sen tilan.

Type=-direktiivi voi olla jokin seuraavista:

• yksinkertainen: Palvelun pääprosessi on lueteltu lähtörivillä. Tämä on oletusarvo, jos Type=- ja Busname=-käskyjä ei ole asetettu, mutta ExecStart= on asetettu. Kaikki viestit on käsiteltävä laitteen ulkopuolella sopivan tyyppisen toisen lohkon kautta (esimerkiksi .socket-lohkon kautta, jos palvelun on tarkoitus kommunikoida socketin avulla).
• haarautuminen: Tämän tyyppistä palvelua käytetään, kun palvelu haarautuu lapsiprosesseihin, kun pääprosessi poistuu hetkellisesti. Tämä kertoo systemdille, että prosessi on edelleen käynnissä, vaikka vanhempi on lopettanut istunnon. Sopii hyvin esimerkiksi php-fpm:n, nginxin, tomcatin ajamiseen.
• yksi laukaus: Tämä tyyppi ilmaisee, että prosessi on lyhytikäinen ja järjestelmän tulee odottaa prosessin valmistumista ennen kuin jatkaa muiden laitteiden kanssa. Type=- ja ExecStart=-oletusarvoja ei ole asetettu. Sitä käytetään kertaluonteisiin tehtäviin.
• dbus: Tämä tarkoittaa, että laite käyttää D-Bus-väylän nimeä. Kun näin tapahtuu, systemd jatkaa seuraavan lohkon käsittelyä.
• ilmoittaa: Tämä tarkoittaa, että palvelu lähettää ilmoituksen, kun se on käynnistynyt. Järjestelmällinen prosessi odottaa tämän tapahtuvan ennen siirtymistä muihin laitteisiin.
• tyhjäkäynnillä: Tämä tarkoittaa, että palvelu ei käynnisty ennen kuin kaikki työt on lähetetty.

Tietyntyyppisiä palveluita käytettäessä voidaan tarvita lisäohjeita. Esimerkiksi:

• RemainAfterExit=: Tätä direktiiviä käytetään yleensä onehot-tyypin kanssa. Tämä tarkoittaa, että palvelua tulee pitää aktiivisena myös prosessin lopettamisen jälkeen.
• PIDFile=: Jos palvelutyypiksi on merkitty "forking", tällä käskyllä ​​asetetaan tiedostopolku, jonka tulee sisältää valvottavan pää"lapsen" prosessitunnus.
• BusName=: Tämä direktiivi on asetettava D-Bus-nimelle, jonka palvelu yrittää saada, kun käytetään "dbus"-palvelutyyppiä.
• NotifyAccess=: Tämä direktiivi määrittää pistorasian, jota tulee käyttää ilmoitusten kuuntelemiseen, kun "ilmoittaa" on valittuna. Se voi olla "ei mitään", "pää" tai "kaikki". Oletusarvo "ei mitään" ohittaa kaikki tilaviestit. "Main"-vaihtoehto kuuntelee pääprosessin viestejä, kun taas "kaikki"-vaihtoehto saa aikaan kaikkien palvelun ohjausryhmän jäsenten käsittelyn.

Toistaiseksi olemme keskustelleet joistakin taustatiedoista, mutta emme ole varsinaisesti kertoneet, kuinka palvelujamme hallinnoidaan. Tätä varten on saatavilla seuraavat ohjeet:

• ExecStart=: Sinun on määritettävä komennon koko polku ja argumentit, jotka on suoritettava prosessin aloittamiseksi. Tämä voidaan määrittää vain kerran (paitsi "onehot"-palveluissa). Jos komentopolkua edeltää "-"-viiva, nollasta poikkeavat poistumistilat hyväksytään ilman, että laitteen aktivointi merkitään epäonnistuneeksi.
• ExecStartPre=: Sinun on määritettävä koko polku ja komentoargumentit, jotka on suoritettava ennen pääprosessin alkamista. Tätä voidaan käyttää useita kertoja.
• ExecStartPost=: Tällä on samat ominaisuudet kuin ExecStartPre =:llä paitsi, että tämä käsky määrittää komennot, jotka suoritetaan pääprosessin alkamisen jälkeen.
• ExecReload=: Tämä valinnainen käsky määrittää komennon, joka tarvitaan palvelukokoonpanon uudelleen lataamiseen, jos sellainen on saatavilla.
• ExecStop=: Tämä osoittaa palvelun pysäyttämiseen tarvittavan komennon. Jos tätä ei ole määritetty, prosessi lopetetaan välittömästi, kun palvelu pysäytetään.
• ExecStopPost=: Tätä voidaan käyttää määrittämään komennot, jotka suoritetaan komennon pysäyttämisen jälkeen.
• RestartSec=: Jos automaattinen palvelun uudelleenkäynnistys on käytössä, tämä määrittää ajan, joka on odotettava ennen palvelun uudelleenkäynnistämistä.
• uudelleenkäynnistys =: Tämä osoittaa olosuhteet, joissa systemd yrittää käynnistää palvelun automaattisesti uudelleen. Se voidaan asettaa arvoon "aina", "on-onnistui", "on-epäonnistui", "on-epänormaali", "on-abort" tai "on-watchdog". Tämä käynnistyy uudelleen sen mukaan, kuinka palvelu pysäytettiin.
• TimeoutSec=: Tämä määrittää ajan, jonka järjestelmä odottaa palvelun pysähtymistä ennen kuin se merkitään epäonnistuneeksi tai pakkotapotuksi. Voit asettaa yksittäisiä aikakatkaisuja komennoilla TimeoutStartSec= ja TimeoutStopSec=.

Socketit ovat hyvin yleisiä systemd-kokoonpanoissa, koska monet palvelut toteuttavat socket-pohjaisen aktivoinnin parantaakseen samanaikaisuutta ja joustavuutta. Jokaisessa liitäntälohkossa on oltava vastaava palvelumoduuli, joka aktivoituu, kun pistoke vastaanottaa toimintaa.

Katkaisemalla socket-hallinnan itse palvelun ulkopuolelta socketit voidaan alustaa aikaisin ja niihin liittyvät palvelut voivat usein toimia rinnakkain. Oletusarvoisesti pistokkeen nimi yrittää käynnistää samannimisen palvelun yhteyden saatuaan. Kun palvelu alustetaan, sille välitetään socket, jonka avulla se voi aloittaa puskuroitujen pyyntöjen käsittelyn.

Varsinaisen pistorasian määrittämiseksi nämä käskyt ovat yleisiä:

• ListenStream=: Tämä määrittää osoitteen socket-streamille, joka tukee johdonmukaista ja luotettavaa viestintää. TCP:tä käyttävien palveluiden on käytettävä tätä liitäntätyyppiä.
• KuunteleDatagram=: Tämä määrittää osoitteen datagrammiliittimelle, joka tukee nopeita, epäluotettavia tietoliikennepaketteja. UDP:tä käyttävien palveluiden on asetettava tämä liitäntätyyppi.
• ListenSequentialPacket=: Tämä määrittää osoitteen johdonmukaista, luotettavaa tiedonsiirtoa varten ja suurinta datagrammia, jotka säilyttävät viestirajat. Tämä on yleisintä Unix-liitännöissä.
• Kuuntele FIFO: Muiden kuuntelutyyppien ohella voit määrittää myös FIFO-puskurin liittimen sijaan.

Yhteyskäskytyyppejä on useampia, mutta yllä olevat ovat yleisimpiä.

Muita pistorasioiden ominaisuuksia voidaan ohjata lisäohjeilla:

• Hyväksy =: Tämä määrittää, käynnistetäänkö palvelun lisäesiintymä yhteyttä kohti. Jos asetettu arvoon false (oletus), yksi esiintymä käsittelee kaikki yhteydet.
• SocketUser=: Asettaa Unix-pistorasian omistajan. Jos sitä ei ole määritetty, käyttäjä on pääkäyttäjä.
• SocketGroup=: Ryhmän omistaja asetetaan Unix-liitännällä. Tämä on juuriryhmä, jos kumpaakaan ei ole määritetty. Jos vain SocketUser= on asetettu, systemd yrittää löytää sopivan ryhmän.
• SocketMode=: Unix-socketeille tai FIFO-puskureille tämä määrittää luodun objektin käyttöoikeudet.
• Palvelu =: Jos palvelun nimi ei vastaa palvelun nimeä .pistoke, tämä palvelu voidaan määrittää käyttämällä tätä direktiiviä.

Kiinnitysmoduulien avulla voit ohjata kiinnityspistettä systemd:n ​​sisältä. Liitäntäpisteet nimetään niiden hallinnoiman hakemiston mukaan käännösalgoritmin avulla.

Esimerkiksi johtava kauttaviiva (vinoviiva tai "/") poistetaan, kaikki muut kauttaviivat käännetään yhdeksi "-" ja kaikki viivat ja ei-tulostavat merkit korvataan C-tyylisillä erotuskoodeilla. Tämän käännöksen tulosta käytetään asennuspalvelimen nimenä. Kiinnitysyksiköillä on implisiittinen riippuvuus hierarkiassa sen yläpuolella olevista muista kiinnikkeistä.

Liitäntäyksiköt käännetään usein suoraan /etc/fstab-tiedostosta käynnistyksen aikana. Automaattisesti luodut yksikkömääritykset ja ne, jotka haluat määrittää yhdessä tiedostossa:

• Mitä =: Absoluuttinen polku liitettävään resurssiin.
• Missä =: sen liitoskohdan absoluuttinen polku, johon resurssi liitetään. Tämän on oltava sama kuin laitteen tiedostonimi, paitsi että käytetään tavallista tiedostojärjestelmän merkintää.
• tyyppi=: Liitettävän tiedostojärjestelmän tyyppi.
• Vaihtoehdot =: Kaikki kiinnitysvaihtoehdot, joita haluat käyttää. Tämä on pilkuilla erotettu luettelo.
• SloppyOptions=: Boolen arvo (0 tai 1), joka määrittää, epäonnistuuko liittäminen, jos asennusvaihtoehto on tuntematon.
• DirectoryMode=: Jos liitoskohtaa varten on luotava ylähakemistoja, tämä määrittää kansioiden käyttöoikeustilan.
• TimeoutSec=: Asettaa ajan, jonka järjestelmä odottaa, kunnes asennustoiminto on merkitty epäonnistuneeksi.

Tämän moduulin avulla voit asentaa kytketyn .mount-moduulin automaattisesti käynnistyksen yhteydessä. Kuten .mount-moduulissa, nämä yksiköt on nimettävä käännetyn liitoskohdan polun mukaan.

Osio on melko yksinkertainen, vain seuraavat kaksi vaihtoehtoa ovat sallittuja:

• Missä =: Automountin absoluuttinen polku tiedostojärjestelmässä. Tämä vastaa tiedoston nimeä, paitsi että polkukäytäntöä käytetään käännöksen sijaan.
• DirectoryMode=:Jos automaattinen asennus tai päähakemistoja on luotava, tämä määrittää näiden polkukomponenttien käyttöoikeusasetukset.

Swap-moduuleita käytetään vaihtamisen (swap) määrittämiseen järjestelmässä. Yksiköt on nimettävä swap-tiedoston tai laitteen nimen mukaan käyttämällä samaa tiedostojärjestelmän siirtoa kuin edellä on käsitelty.

Kuten asennusvaihtoehdot, swap-lohkot voidaan luoda automaattisesti hakemistosta /etc/fstab tai ne voidaan määrittää erillisen yksikkötiedoston kautta.

Osio voi sisältää seuraavat konfigurointiohjeet:

• Mitä =: Absoluuttinen polku swap-sijaintiin (olipa se tiedosto tai laite).
• Prioriteetti=: Tämä vaihtoehto hyväksyy kokonaisluvun, joka määrittää swap-asetuksen prioriteetin.
• Vaihtoehdot =: Kaikki asetukset, jotka normaalisti asetetaan /etc/fstab-tiedostoon, voidaan asettaa tällä käskyllä. Pilkuilla eroteltua luetteloa käytetään.
• TimeoutSec=: Tämä asetus määrittää ajan, jonka järjestelmä odottaa vaihdon aktivointia ennen kuin toiminto merkitään epäonnistuneeksi.

Polkulohko määrittää tiedostojärjestelmän polun, jonka järjestelmä voi seurata muutoksia. On oltava toinen lohko, joka aktivoituu, kun polun sijainnissa havaitaan tiettyä toimintaa. Polun aktiivisuus määräytyy sen perusteella, että se ei vaikuta tapahtumiin.

Osio voi sisältää seuraavat ohjeet:

• PathExists=: Tätä ohjetta käytetään tarkistamaan, onko polku olemassa. Jos polku on olemassa, vastaava lohko aktivoituu.
• PathExistsGlob=: Tämä vaihtoehto on sama kuin yllä, mutta tukee globaaleja lausekkeita polun olemassaolon määrittämiseksi.
• PathChanged=: Tätä vaihtoehtoa käytetään polun sijainnin muutosten seuraamiseen. Liitetty lohko aktivoituu, jos havaitaan muutos (tarkistetaan, kun tiedosto suljetaan).
• PathModified=: Tämä vaihtoehto on sama kuin yllä, mutta se aktivoituu tiedostoja kirjoitettaessa ja myös silloin, kun tiedosto suljetaan.
• DirectoryNotEmpty=: Tämä direktiivi sallii systemd:n ​​aktivoida siihen liittyvän lohkon, kun hakemisto ei ole enää tyhjä.
• yksikkö=: Tämä osoittaa, että laite on aktivoitu, kun yllä olevat polun ehdot täyttyvät. Jos tämä jätetään pois, systemd etsii .service-tiedoston, jolla on sama perusyksikön nimi kuin tällä lohkolla.
• MakeDirectory=: Tämä direktiivi määrittää, luoko systemd hakemistorakenteen ennen selaamista.
• DirectoryMode=: Jos yllä oleva direktiivi on käytössä, tämä vaihtoehto asettaa kaikkien luotavien polun komponenttien käyttöoikeustilan.

Ajastinyksikkö, jota käytetään tehtävien ajoittamiseen tiettyyn aikaan tai tietyn viiveen jälkeen. Tämä laitetyyppi korvaa tai täydentää joitain cron- ja daemon-toimintoja. Asianmukainen lohko on järjestettävä, joka aktivoituu, kun ajastin saavutetaan.

Osio voi sisältää joitain seuraavista ohjeista:

• OnActiveSec=: Tämä direktiivi sallii vastaavan lohkon aktivoinnin suhteessa .timer-moduulin aktivointiin.
• OnBootSec=: Tämä direktiivi asettaa ajan, jolloin vastaava laite aktivoidaan järjestelmän käynnistyksen jälkeen.
• OnStartupSec=: Tämä ohje on samanlainen kuin yllä oleva ajastin, mutta määrittää, milloin systemd-prosessi herää järjestelmän käynnistyksen jälkeen.
• OnUnitActiveSec=: Tämä asettaa ajastimen sen mukaan, milloin viimeksi aktivoitiin.
• OnUnitInactiveSec=: Tämä asettaa ajastimen, kun laite ei ollut aktiivinen.
• OnCalendar=: Tämän avulla voit aktivoida vastaavan lohkon määrittämällä absoluuttisen (suhteellisen sijaan).
• AccuracySec=: Tätä yksikköä käytetään liimattavan ajastimen tarkkuustason asettamiseen. Oletusarvoisesti siihen liittyvä lohko aktivoidaan minuutin kuluessa.
• yksikkö=: Tätä ohjetta käytetään määrittämään, mitä aktivoidaan ajastimen umpeutuessa. Jos sitä ei ole asetettu, Systemd etsii lohkon nimeltä .service.
• Pysyvä =: Jos tämä on asetettu, Systemd suorittaa asianmukaisen lohkon liipaisimen.
• WakeSystem=: Tämän ohjeen asettaminen sallii järjestelmän "herätyksen" valmiustilasta, jos ajastin saavutetaan.

Osalla ei itse asiassa ole .slice-kohtaista määritystä. Sen sijaan se voi sisältää joitain yllä luetelluista resurssienhallintaohjeista.

Teoriaa riittää, siirrytään käytäntöön.

Systemd Unit -tiedoston kirjoittaminen

Ensimmäinen asia on tarkistaa alustus:

# ps -s1| awk "(tulosta 4 dollaria)"| grep -Ev "CMD"

PS: Tässä lyhyt artikkeli:

Lohkomallitiedostot voidaan määrittää, koska ne sisältävät @-merkin peruslohkon nimen jälkeen ja ennen lohkotyypin päätettä. Mallin sisältävän lohkotiedoston nimi saattaa näyttää tältä:

[sähköposti suojattu]

Luodusta lohkosta (joka on yllä) voit luoda esiintymän toisesta lohkosta, joka näyttää tältä:

[sähköposti suojattu]

Mallimoduulitiedostojen teho johtuu pääasiassa kyvystä lisätä dynaamisesti oleellista tietoa laitemäärittelyyn ympäristön (ENV) mukaan. Tämä tehdään asettamalla käskyjä mallitiedostoon tavalliseen tapaan, mutta korvaamalla tietyt arvot tai arvojen osat muuttujamääritteillä.

Seuraavassa on joitain yleisimmistä määrityksistä, jotka korvataan, kun ilmentymäyksikkö tulkitaan asianmukaisilla tiedoilla:

• %n: Aina kun tätä käytetään, elementin koko nimi lisätään.
• %N: Tämä on sama kuin yllä, mutta kaikki poistomerkit, kuten tiedostopolkukuvioissa olevat, jätetään pois.
• %p: Tämä määrittää yksikön nimen etuliitteen. Tämä on se osa yksikön nimestä, joka edeltää @-symbolia.
• %P: Tämä on sama kuin edellä, mutta poikkeuksin.
• %i: Tämä viittaa ilmentymän nimeen, joka on ilmentymän @-merkkiä seuraava tunniste. Se on yksi yleisimmin käytetyistä määrityksistä, koska se on dynaaminen. Tämän tunnisteen käyttö rohkaisee mielekkäiden määritystunnisteiden käyttöön. Esimerkiksi porttia, jolla palvelu suoritetaan, voidaan käyttää ilmentymän tunnisteena, ja malli voi käyttää tätä määritystä porttimäärittelyn mukauttamiseen.
• %I: Tämä määrite on sama kuin edellä, mutta poikkeuksin.
• %f: Tämä korvataan yksikön nimellä, jossa ei ole koodimerkkiä tai etuliitenimellä, joka on liitetty kohtaan "/".
• %c: Tämä osoittaa laitteen ohjausryhmään, jossa on normaali päähierarkia /sys/fs/cgroup/ssytemd.
• %u: Käyttäjätunnus, joka on määritetty käyttämään laitetta.
• %U: Sama kuin yllä, UID nimen sijaan.
• %H: Sen järjestelmän isäntänimi, jossa yksikkö toimii.
• %% : Tätä käytetään lisäämään aakkosellinen prosenttimerkki.

Käyttämällä yllä olevia tunnisteita tiedostomallissa, Systemd täyttää oikeat arvot tulkitessaan mallia yksikköinstanssin luomiseksi.

Esimerkkejä järjestelmäyksikön tiedostoista

Harkitse seuraavaa esimerkkiä - tämä on systemd-komentosarjan kirjoittaminen tomcatin käynnistämiseksi. Voit tehdä tämän avaamalla tiedoston:

# vim /etc/systemd/system/tomcat9.service

Ja kirjoita siihen seuraava koodi:

Kuvaus=Tomcat9 After=syslog.target network.target Type=forking User=tomcat Group=tomcat Environment=CATALINA_PID=/usr/local/tomcat9/tomcat9.pid Environment=TOMCAT_JAVA_HOME=/usr/bin/java Environment=CATALINA_HOME=/usr /local/tomcat9 Ympäristö=CATALINA_BASE=/usr/local/tomcat9 Ympäristö=CATALINA_OPTS= #Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -palvelin -XX:+UseParallelGC" Environment="JAVA_OPTS=-Dfile.8 -=Dfile.encoding Dnet.sf.ehcache.skipUpdateCheck=true -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:MaxPermSize=128m -Xms512m -Xmx512m" ExecStart=//sbintopS/locsh =/bin/kill -15 $MAINPID WantedBy=multi-user.target

Aloitetaan palvelu uudelleen:

# systemctl daemon-reload

Lisää Tomcat käyttöjärjestelmän käynnistykseen:

# systemctl salli tomcat9

Käynnistä tomcat uudelleen:

# systemctl käynnistä tomcat9 uudelleen

Tarkistaaksesi tilan, suorita:

# systemctl tila tomcat9 ● tomcat9.service - Tomcat9 Ladattu: ladattu (/etc/systemd/system/tomcat9.service; käytössä) Aktiivinen: aktiivinen (käynnissä) tiistaista 2017-05-09 22:04:58 EEST; 6 s sitten Prosessi: 28528 ExecStop=/bin/kill -15 $MAINPID (koodi=poistunut, status=0/MENNISTYS) Prosessi: 28531 ExecStart=/usr/local/tomcat9/bin/startup.sh (koodi=exited, status= 0/SUCCESS) Pää-PID: 28541 (java) CGroup: /system.slice/tomcat9.service └─28541 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat9/conf/ logging.properties -Djava.ut... 9. toukokuuta 22:04:58 debian systemd: Tomcat9:n käynnistys... 9. toukokuuta 22:04:58 debian startup.sh: Tomcat käynnistyi. 9. toukokuuta 22:04:58 debian systemd: Käynnistettiin Tomcat9.

Kuten näet, kaikki toimii hyvin. Tässä minulla on kaikki! Esimerkkejä tulee lisää. Lisään niitä tarpeen mukaan. Mutta periaatteessa käytän yllä olevaa mallia (muokkaa vain sitä hieman).

Artikkeli "Järjestelmän yksikkötiedoston kirjoittaminen" on valmis.

Järjestelmän demonit ovat yksi tärkeimmistä UNIX-alijärjestelmistä. Ei vain käyttöjärjestelmän ominaisuudet, vaan myös parametrit, kuten helppokäyttöisyys ja tasainen työn nopeus, riippuvat siitä, kuinka hyvin ja oikein ne on kirjoitettu. Tässä artikkelissa tarkastellaan neljää esimerkkiä demonien oikeasta toteutuksesta, jotka voivat tehdä järjestelmässä työskentelemisestä mukavampaa, tehokkaampaa ja nopeampaa.

systemd: nopeampi kuin valo

Tyypillisen Linux-jakelun käynnistyskaavio näyttää suunnilleen tältä: ydin alustaa laitteiston ja käynnistää /sbin/init-prosessin, joka puolestaan ​​suorittaa alustuskomentosarjat. Skriptit liittävät tiedostojärjestelmät, määrittävät verkon, eri laitteet ja käynnistävät peräkkäisen demonien: syslogd, cron, cups ja muut, jotka on lueteltu asetustiedostoissa. Aivan lopussa init käynnistää kirjautumishallinnan: getty tai xdm (kdm, gdm). Yksinkertaista ja loogista, eikö? Tällainen järjestelmä on kuitenkin melko primitiivinen, ja verrattuna Windowsiin ja Mac OS X:ään se on yleensä arkaainen. Niiden alustusjärjestelmät suorittavat tehtäviä rinnakkain odottamatta yhden suorittamista ennen kuin siirtävät hallinnan seuraavalle. Jos yksi niistä pysähtyy I/O:ssa, toinen ottaa hallinnan välittömästi, joten kokonaislatausaika lyhenee niin paljon, että perinteinen järjestelmä on paljon jäljessä.

Linux-maailmassa vain Ubuntu käyttäytyy tällä tavalla, ja silloinkin vain viimeisen kahden vuoden ajan. Kaikki muut jatkavat järjestelmän käynnistämistä vanhanaikaisesti tai käyttävät itse koottuja kainalosauvoja, jotka rinnastavat käynnistysprosessin huonosti ja usein virheellisesti (Gentoo ja Arch, hei!). Todella universaalia ratkaisua ei ole vielä löydetty, joten monet ohjelmoijat työskentelevät ajatuksen rinnakkaisesta alustusjärjestelmästä.

Red Hatin Lennart Pottering ja PulseAudion kirjoittaja on yksi heistä. Hänen viimeisin saavutuksensa on systemd-daemon, toinen kilpailija /sbin/init-killer -tittelistä, joka olisi voitu helposti ohittaa, jos sen taustalla oleva idea ei olisi osoittautunut niin mielenkiintoiseksi ja oikeaksi.

Systemd eroaa kaikista muista aloitusjärjestelmistä siinä, että se tekee monimutkaisista asioista tarkoituksella yksinkertaisia. 99% kaikista muista samanaikaisista init-järjestelmistä epäonnistui yksinkertaisesti siksi, että verrattuna yksinkertaiseen ja jopa villiin /sbin/init ymmärrettävään, ne näyttivät raskaansarjan hirviöiltä. Jotta voidaan ajaa rinnakkain ilman, että käyttöjärjestelmä tulee epäjohdonmukaiseen tilaan (mitä voi tapahtua esimerkiksi, jos yrität määrittää verkon ennen verkkoajurien lataamista tai käynnistää demonit asentamatta oikeaa FS:ää), erilaisia ​​synkronointeja. menetelmiä käytettiin. Pohjimmiltaan nämä olivat eräänlaisia ​​"riippuvuusmerkkejä", jotka eivät antaneet seuraavan alustusvaiheen toimia, jos sen riippuvuuksissa kuvattu vaihe jäi kesken.
Esimerkiksi cron riippuu syslogista, koska sen on säilytettävä lokeja; syslog riippuu verkon asetuksista, koska se pystyy vastaanottamaan lokeja etäkoneista ja niin edelleen. Tämän vuoksi alustusskriptit muuttuivat hämmentäväksi lohkojonoksi, ja niiden kokoamisesta tuli paljon monimutkaisempi. Systemd on paljon yksinkertaisempi, se ei seuraa riippuvuuksia, se vain suorittaa kaiken samanaikaisesti.

En vitsaile. Systemd käyttää riippuvuuden hallintamekanismeja vain alustamisen varhaisessa vaiheessa, jonka on tapahduttava jotenkin peräkkäin (juuritiedostojärjestelmän liittäminen, swapin asennus, moduulien lataaminen ja niin edelleen). Mitä tulee demoniin, joiden käynnistyminen vie 90 % käyttöjärjestelmän alustusajasta, systemd unohtaa riippuvuudet ja käynnistää ne kaikki kerralla näyttäen uskomattoman nopeaa.

Tämä toimii, koska systemd on tietoinen demonien toiminnasta ja siitä, kuinka ne kommunikoivat keskenään.

Itse asiassa demonit eivät todellakaan tarvitse muita demoneja, vaan vain "viestintäkanavia", jotka tarjoavat tiedonvaihtoa: cron ei ole riippuvainen syslogista, se tarvitsee /dev/log-pistokkeen, johon se voi kirjoittaa lokinsa, sama on totta kaikille muille demonille. Ne kaikki kommunikoivat sockettien kautta, ja ainoa syy miksi demoni A on käynnistettävä ennen demoneja B, C ja D, on se, että demonin A on luotava heidän tarvitsemansa pistoke. Systemd ottaa tämän huomioon, joten sen rinnakkaiskäynnistysmekanismi luottaa pistokkeisiin, jotka se luo kullekin demonille etukäteen ja käynnistää sitten demonit samanaikaisesti. Samalla vastuu synkronoinnista ja "riippuvuuden seurannasta" siirtyy nyt ytimelle, jonka sisällä socket-mekanismi on toteutettu.

Jos esim. cron saa kontrollin ennen syslogia, mitään pahaa ei tapahdu - cron löytää suosikkinsa / dev / log ja pystyy jopa kirjoittamaan sille viestejä (jos haluaa tietysti), mikä ei, ei, heitetään ulos, mutta puskuroidaan socketissa, mutta vain siihen asti, kunnes cron haluaa kirjoittaa pistokkeeseen viestin, joka voi täyttää sen. Tässä tapauksessa ydin estää cron-prosessin ja siirtää ohjauksen seuraavalle prosessille suoritusjonossa (seuraavalle demonille). Pian (tai ehkä heti) jono saavuttaa syslogin, joka alkaa, lukee / dev / log -kansioon kertyneet viestit, käsittelee ne ja estää itsensä joltakin (tai käyttää sille varatun ajan), ja ohjaus siirtyy seuraava demoni. Tyypillistä moniajoa ilman ylimääräisiä kainalosauvoja.

Lisäksi tämän järjestelmän ansiosta useimmat demonit voidaan käynnistää vain silloin, kun niitä todella tarvitaan. Joten esimerkiksi CUPS:ää ei tarvitse käynnistää käyttöjärjestelmän alustuksen aikana, kun järjestelmän kuormitus on jo korkea. On loogisempaa käynnistää se, kun ensimmäinen asiakirja lähetetään tulostettavaksi. Systemd antaa sinun tehdä tämän pitämällä silmällä socketin toimintaa, ja se käyttää samanlaista lähestymistapaa tiedostojärjestelmien liittämiseen liittämällä ne vain liitospisteisiin, kun yrität käyttää tiedostoja (daemonit voidaan käynnistää myös, kun tietty laitetiedosto ilmestyy järjestelmään) .

Rehellisyyden nimissä on syytä sanoa, että tällainen nerokas ratkaisu riippuvuusongelmaan keksittiin ja toteutettiin Mac OS X:ssä sen olemassaolon alusta lähtien, mutta jostain syystä kukaan ei kiinnittänyt siihen huomiota ennen systemd:n ​​kirjoittajaa.

Muuten, systemdillä itsessään on toinen ominaisuus, joka on selkeästi ainutlaatuinen Linuxille: se voi ryhmitellä prosesseja käyttämällä c-ryhmiä erilaisilla ajonaikarajoituksilla koko ryhmässä (resurssirajat, työ- ja juurihakemistot, umask, OOM-killer-asetukset, mukava parametri, toiminnan prioriteetti I/O, suorittimen käyttöprioriteetit ja paljon muuta). Toisin sanoen demonit voidaan nyt sijoittaa virtuaalisiin ympäristöihin ilman lisäohjelmistoja, yksinkertaisesti kirjoittamalla muutama rivi systemd-määritystiedostoon.

Systemd on jo ladattavissa, ja se voidaan sisällyttää Fedoran tulevaan julkaisuun vaihtoehtoisena aloitusjärjestelmänä. Muiden jakelujen asennusohjeet löytyvät viralliselta sivulta: freedesktop.org/wiki/Software/systemd.

Voit asentaa Systemdin Ubuntuun suorittamalla seuraavat komennot:

$ sudo add-apt-arkisto ppa:andrew-edmunds/ppa
$ sudo apt-get päivitys
$ sudo apt-get install systemd

Muokkaa seuraavaksi tiedostoa /boot/grub/grub.cfg ja lisää rivi init=/sbin/systemd ytimen parametreihin. Uudelleenkäynnistyksen jälkeen jakelu toimii uuden init-järjestelmän kanssa, joka voidaan tarkistaa komennolla:

$ sudo systemctl units-list

Status-, start-, stop- ja enable-argumentteja käytetään tilan, aloituksen, pysäytyksen ja palvelujen ottamiseksi käyttöön tarkistamiseen.

Ulatenssi: välitön reaktio

Mikä on mielestäsi työpöytäkäyttöjärjestelmän tärkein parametri? Hyvä graafinen käyttöliittymä? Käytettävissä olevien sovellusten määrä? Helppokäyttöisyys?

Kyllä, tällä kaikella on merkitystä, mutta nykyään, kun jopa palvelinkäyttöjärjestelmät voidaan helposti varustaa näillä ominaisuuksilla, ratkaisevat aivan erilaiset tekijät, joista tärkein on järjestelmän reagointikyky.

Hyvän työpöytäkäyttöjärjestelmän on uhrattava kaikki korkean reagointikyvyn vuoksi. Riippumatta siitä, mitä nopeutta se näyttää kirjoittaessaan tiedostoja levylle, kuinka monta työpöytätehostetta se tarjoaa käyttäjälle, reagoiko se oikein flash-aseman äkilliseen poistoon, kaikella ei ole väliä, jos käyttöjärjestelmä pakottaa käyttäjän odottamaan.

Käyttöjärjestelmien kehittäjille tämä on yleinen totuus, joten he ovat aina pyrkineet tekemään käyttöjärjestelmistään interaktiivisempia. Toisilla se onnistui hyvin (hei BeOS), toisilla ei toiminut hyvin (missä ilman MS-tautia), mutta oli myös niitä, jotka eivät onnistuneet ollenkaan. Pitkään aikaan Linux-kehittäjät eivät olleet lainkaan kiinnostuneita Linuxin reagointikyvystä pöytätietokoneissa. Con Kolivas huomautti heille monta kertaa ongelmista, puhui Linuxin hitaudesta ja hitaudesta, kirjoitti korjaustiedostoja, koodasi uusia tehtävien ajoittajia yöllä ja pyrki sisällyttämään ne ytimeen. Kaikki turhaan, yhä uudelleen ja uudelleen laastarit hylättiin, ja itse kirjoittaja poistettiin töykeästi liiketoiminnasta.

Ajan myötä Kon Kolivaksen työ kuitenkin kannatti. Ingo Molnar luki lähteensä ja kirjoitti CFS (Completely Fair Scheduler) -aikataulun, ja Linux sisällytti sen välittömästi 2.6.23-ytimeen. Sittemmin asiat ovat parantuneet paljon pöytäkoneissa, ja Linuxista on tullut paljon nopeampi (vaikka Kohnin toteutus on joka tapauksessa näyttänyt vaikuttavampia tuloksia).

Toinen merkittävä virstanpylväs Linuxin tiellä työpöydälle oli kuuluisan 200-sivuisen korjaustiedoston sisällyttäminen 2.6.38-ytimeen sekä sen vastineen ilmestyminen bash-kieleen. Joten Linux oppi erottamaan interaktiiviset prosessit kaikista muista demoneista, palvelimista ja bash-skripteistä ja antamaan niille korkeammat prioriteetit. Tämä tapahtuma paransi tilannetta entisestään ja teki siitä lähes ihanteellisen: nyt Linux ei hidastunut, vaikka ydintä rakennettiin uudelleen useiksi säikeiksi taustalla.
Lopuksi kolmas tärkeä askel pöytätietokoneille Linuxille (ja tässä tulen tärkeimpään) oli ulentenssi-daemonin ilmestyminen, joka voi dynaamisesti säätää järjestelmän reagointikykyä mukauttaen sitä muuttuviin olosuhteisiin.

Kuten ytimen korjaustiedosto, ulencyd käyttää cgroups-mekanismia interaktiivisten prosessien ryhmittelyyn ja niiden prioriteettien muuttamiseen, mutta sen työ ei lopu tähän. Daemon käyttää heuristiikkaa tunnistaakseen "interaktiivisimmat" prosessit sekä ilmeiset järjestelmän sabotoijat, kuten haarukkapommit ja ohjelmat, joissa on suuria muistivuotoja. Samaan aikaan ensimmäiset saavat vielä suuremman prioriteetin, kun taas jälkimmäisten kykyjä rajoitetaan voimakkaasti (saanot alhaisen prioriteetin, käytettävissä olevan muistin rajoitukset), eristettyjä tai tuhottuja. Mutta mikä tärkeintä, demonille voidaan milloin tahansa opettaa uusia prosessinvalintasääntöjä, jotta voimme nyt määrittää korkeimmat (jopa reaaliaikaiset) prioriteetit suosikkipeleillemme, videosoittimillemme ja selaimillemme.

Daemon tukee laajennuksia, joten sen toimintoja voidaan laajentaa upeisiin mahdollisuuksiin. Esimerkiksi laajennus on jo saatavilla (ja vakiona), joka valvoo käyttäjän työtä X:ssä ja asettaa korkeimmat prioriteetit juuri avatuille sovelluksille ja prosesseille, joiden ikkunat ovat etualalla.

Ladataksesi ulatencyd:n sen lähteet sivulta ja rakennettava se käyttämällä standardia cmake ja make:

$cmake
$make
$ sudo tee asennus

$ sudo /usr/local/sbin/ulatencyd -v 2

Ja katso, kuinka hän ryhmittelee prosessit prioriteettien mukaan:

$ ps xaf -eo pid,session,args,cgroup

Asetuksia ei tarvitse tehdä. Oletusarvoisesti demoni suosii multimediaa ja eniten käytettyjä interaktiivisia sovelluksia, jolloin taustatehtävät voivat toimia hiljaa häiritsemättä pääjärjestelmää.

rele: kolmella rintamalla

Mikä on verkkoisäntävalvonnan, kuormituksen tasapainotuksen ja välityspalvelimen välinen suhde? Ovatko nämä kaikki yhden koneen toiminnot? Kyllä, se on täysin mahdollista. Mutta entä jos sanon, että kaikki nämä kolme toimintoa liittyvät läheisesti toisiinsa ja että ne pitäisi toteuttaa yhdessä yleisessä sovelluksessa? Rave? Ei lainkaan.

Otetaan esimerkiksi melko yleinen palvelintoiminto kapeissa piireissä nimeltä "kuormituksen tasapainottaminen useiden DNS-palvelimien välillä". Mitä sen ratkaisemiseksi tarvitaan? Ensinnäkin kyky ohjata DNS-liikennettä toiseen isäntään (tasapainottimesta johonkin todellisista DNS-palvelimista).

Tämä voidaan tehdä palomuurin tai erityisesti määritetyn BINDin (jossain määrin raskaan) kautta. Toiseksi, kyky valita sopivin ehdokas pyynnön käsittelyyn DNS-palvelimien luettelosta. Tämä on jo monimutkaisempi, ja tässä saatat tarvita erikoisohjelmistoa tai taas palomuuria (mutta erittäin hyvää). Kolmanneksi mahdollisuus tarkistaa DNS-palvelimien saatavuus ja poistaa luettelosta pudonneet. Tarvitset komentosarjan, joka ping-kutsua isäntiä ja hallitsee luetteloita, tai erityisiä palomuuriominaisuuksia (onko sellaista olemassa?). Yleensä pitkä ikävä polkupyörän rakentaminen tai erikoisratkaisun ostaminen tiettyyn tehtävään epärealistisella hinnalla. Mutta entä jos huomenna joudut yhtäkkiä tekemään jotain vastaavaa SMTP:lle?

Muokkaako vai avataanko lompakko uudelleen? Ei kannata, on parempi säästää lompakon sisältö ja jättää kainalosauvat polkupyörillä urheilijoille. OpenBSD 4.3:ssa esitellyllä välitysdaemonilla voit ratkaista tämän ja valtavan määrän muita tehtäviä, samanlaisia ​​ja ei niin, muutamassa minuutissa.

Se sisältää kerroksen 3, 4 ja 7 protokollien kuormituksen tasapainottimen, kerroksen 7 välityspalvelimen (releet) ja palvelun verkkosolmujen saatavuuden tarkistamiseksi (josta se kasvoi).

Voit rakentaa laajan valikoiman välityspohjaisia ​​konfiguraatioita yksinkertaisista välityspalvelimista tai SSL-kiihdyttimistä monimutkaisiin ratkaisuihin, kuten läpinäkyviin verkkovälityspalvelimiin, joissa on pyyntösuodatus ja kuormituksen tasapainotus useiden verkkopalvelimien välillä. Ja kaikki tämä yksinkertaisen asetustiedoston avulla, jonka pituus jopa monimutkaisimmissa kokoonpanoissa harvoin ylittää 50 riviä.

Kyllä, tietysti, ilman esimerkkiä, kaikki nämä ovat vain sanoja. Joten tässä on toimiva konfiguraatio, joka täyttää täysin osan alussa esitetyt vaatimukset:

#vi /etc/relayd.conf

Muuttujat ja makrot

Releemme osoite ja portti

relayd_addr="127.0.0.1"
relayd_port="8053"

Kolmen käsiteltävän DNS-palvelimen osoitteet

pyynnöt

pöytä { 192.168.1.1, 192.168.1.2, 192.168.1.3 }

Yleiset asetukset

Isäntä tarkistaa saatavuuden

(10 sekuntia)

Aikakatkaisu isäntien saatavuuden tarkistamiselle TCP-menetelmällä

(jos isäntä ei vastaa yli 200 ms:iin - se on pois päältä)

Jaamme palvelimen viiteen prosessiin tehokkuuden lisäämiseksi

pyynnön käsittely

Kirjaa tulokset isäntien saatavuuden tarkistamisesta

DNS-protokollan asetukset

Yhteyden optimointiasetukset

dns-protokolla "dnsfilter" ( tcp ( nodelay, sack, socket buffer 1024, backlog 1000 ) )

Releasetukset

välitä dnsproxy(

Kuunteluosoite ja portti

kuuntele $relayd_addr portista $relayd_port

Työskentelemme aiemmin kuvatulla protokollalla

protokolla "dnsfilter"

Lähetämme DNS-paketit johonkin taulukossa luetelluista

DNS-palvelimet, kun olet tarkistanut sen saatavuuden

eteenpäin portti 53
tilan kuormituksen tasapainon tarkistus tcp
}

Tämän konfiguraation tärkeimmät osat ovat dns-protokollan ja välitysohjeiden rungossa. Ensimmäinen on eräänlainen malli, jota käytetään välttämään samojen protokolla-asetusten toistamista muissa määritystiedoston osissa (relayd tukee kolmea protokollaa: HTTP, DNS ja TCP). Toinen on välitysasetus, joka määrittää kuunteluportin, välityspalvelinprotokollan, sen asetukset ja tiedot siitä, kuinka ja mihin isäntään paketit uudelleenohjataan. Meidän tapauksessamme välityspalvelimen on lähetettävä DNS-kysely yhdelle kolmesta palvelimesta saavutettavuuden esitarkastuksella (tämä käyttää TCP-kättelyä, mutta välitys tukee monia muita menetelmiä aina pingistä SSL-yhteyden muodostamiseen). Samanaikaisesti, jos jokin DNS-palvelimista on poissa käytöstä, relayd sulkee sen automaattisesti pois luettelosta, kunnes ajoitettu käytettävyystarkistus (tarkistusten välinen aika on määritetty intervallivaihtoehdossa) osoittaa sen toimivuuden.

Voit käyttää seuraavaa välityskäynnistyslomaketta kokoonpanosi testaamiseen:

# relayd -d -vv -f /etc/relayd.conf

Joten demoni ei mene taustalle ja pitää yksityiskohtaisen luettelon kaikista toimistaan. Määrityksen virheenkorjauksen jälkeen voit määrittää demonin käynnistymään järjestelmän käynnistyksen yhteydessä. Voit tehdä tämän kirjoittamalla rivin relayd_flags="" /etc/rc.conf.local-tiedostoon.

FreeBSD fscd: minimalismin kauneus

Tämän osion ei olisi pitänyt olla artikkelissa. Fscd-daemon on niin yksinkertainen työkalu, että tuntui tarpeettomalta kirjoittaa siitä erikseen. Toisaalta on mahdotonta olla kirjoittamatta siitä, koska se on yksi selkeimmistä esimerkeistä UNIX-tyylisen ongelman oikeasta ratkaisusta. Ja FreeBSD-kehittäjien tehtävä oli seuraava.
Eri järjestelmät ja ei niin demonit voivat kaatua ajoittain (tai alkaa käyttäytyä kuin idiootit, mikä on vielä pahempaa). Kotikoneessa tämä ei ole pelottavaa, pudonneen koneen voi käynnistää uudelleen käsin tai lähettää tietokoneen uudelleenkäynnistykseen. Mutta mitä tehdä palvelimella, jossa järjestelmänvalvoja on harvinainen?

Palveluita tulee seurata ja käynnistää uudelleen tarpeen mukaan. Kuinka tehdä se? Luonnollisesti rakentaa tämä toiminnallisuus alustusjärjestelmään (hän ​​on se, joka käynnistää demonit). Ja esimerkiksi Solaris teki juuri niin, niin ylevästi, että Linus Torvalds itse katkaisi jalkansa, kun hän keksi, kuinka se konfiguroidaan. FreeBSD-kehittäjät ottivat sen rauhallisesti. He ovat kirjoittaneet erillisen daemonin, joka pystyy ajamaan FreeBSD:n aloitusskriptejä pysyen täysin itsenäisenä järjestelmänä. Asia on siinä, että fscd on niin yksinkertainen, että voit käyttää sitä lukematta man-sivuja tai murehtimatta sen kaatumisesta. Päättele itse, jos haluat tehdä fscd-näytön, esimerkiksi sshd:n, sinun on syötettävä vain yksi komento:

# fscadm enable sshd /var/run/sshd.pid

Siinä kaikki, fscd muistaa tämän valinnan ja ottaa valvonnan automaattisesti käyttöön, kun kone käynnistetään uudelleen. Ainoa ehto on, että ohjatulla demonilla on oltava alustustiedosto hakemistossa /etc/rc.d (tai /usr/local/etc/rc.d) ja merkintä /etc/rc.conf-tiedostossa, joka sisältää sen (tämä on ilmeistä).

Fscd-daemon on saatavilla vain FreeBSD 9.0:ssa, mutta se on täysin mahdollista ladata viralliselta sivulta (people.freebsd.org/~trhodes/fsc) ja rakentaa se 8.0:lle.

johtopäätöksiä

Joka päivä UNIXin maailmaan ilmestyy jotain uutta, mutta hyvin harvoin tämä uusi osoittautuu huomiomme arvoiseksi. Tässä artikkelissa puhuin neljästä UNIX-järjestelmän komponentista, jotka eivät vain ansaitse erityistä huomiota, vaan ovat myös todella hyödyllisiä. Kuka tietää, ehkä tulevaisuudessa niistä tulee yhtä kiinteä osa UNIXia kuin grep-komento tai syslog-daemon.

Linkit

• systemd:n ​​koti siiven alla: freedesktop.org/wiki/Software/systemd ; freedesktop.org
• systemd-lähteet: cgit.freedesktop.org/systemd ;
• ulentenssikoodi: github.com/poelzi/ulatencyd ;
• fscd-lähteet: people.freebsd.org/~trhodes/fsc.

tiedot

• Pitkällä aikavälillä kirjoittaja aikoo tehdä systemdistä täysivaltaisen istunnonhallinnan, joka voi korvata gnomesessionin ja kdeinit.
• Systemd:ssä on muun muassa daemon-valvontatoimintoja, joten fscd:n ominaisuudet on sisäänrakennettu siihen syntymästä lähtien.
• Skriptien käyttämättä jättäminen on yksi tapa nopeuttaa latausprosessia. Systemd voi suorittaa monia alustustehtäviä kutsumalla suoraan tarvittavat komennot ilman komentosarjoja.
• Relayd - hostated (sanoista isäntätila, "isäntätila") entinen nimi muutettiin nykyiseksi toiminnallisuuden laajentamisen yhteydessä.

systemd on uusi Linux-järjestelmän alustusdaemon, jonka pitäisi lopulta korvata klassinen SysV initd -daemon. Tärkeimmät tehtävät, jotka se on suunniteltu ratkaisemaan, ovat ensinnäkin järjestelmän käynnistyksen nopeuttaminen maksimoimalla rinnakkain käynnissä olevien palvelujen määrä, toiseksi järjestelmän hallittavuuden parantaminen Linux-ytimen tarjoamien erityisominaisuuksien avulla ja kolmanneksi koko järjestelmän yhdistäminen. asetukset ja koodin maksimaalinen yleistys eri palvelujen käynnistämiseksi. Ainakin siltä minusta tuntui dokumenttien luettuani.

Haluan kiittää Sergey Ptashnikia erinomaisesta systemd-dokumentaation käännöksestä: systemd järjestelmänvalvojalle itse järjestelmän tekijältä, Lennart Poteringilta. Haluan myös kiittää lukuisista asiakirjoihin liittyvistä huomautuksista, jotka ovat aina paikallaan. Tämä ja myöhemmät huomautukseni perustuvat olennaisesti tähän dokumentaatioon tai pikemminkin sen PDF-versioon.

1. Asenna systemd

Systemd:n ​​asentaminen on melko helppoa. Asenna paketti ensin:
# apt-get install systemd Ja kirjoita systemd:n ​​käyttö Linux-ytimen asetuksiin. Voit tehdä tämän avaamalla tiedoston GRUB 2 -käynnistyslataimen asetuksilla:
# vi /etc/default/grub Ja lisää lisävaihtoehto init=/lib/systemd/systemd asetukseen GRUB_CMDLINE_LINUX_DEFAULT. Muokkauksen jälkeen tämä vaihtoehto näyttää tältä:
GRUB_CMDLINE_LINUX="video=VGA-1:640x480 video=TV-1:640x480 rootfstype=ext4 init=/lib/systemd/systemd" Ota nyt muutokset käyttöön luomalla uusi käynnistyslataimen asetustiedosto:
# update-grub Nyt voit käynnistää järjestelmän uudelleen aloittaaksesi systemd:n ​​käytön:
# sammutus -r nyt 2. Ongelmanratkaisu

2.1. Tekstikonsolin lokalisointi

Ensimmäinen ongelma, johon törmäsin, oli virhe konsoli-kyrillisen skriptin suorittamisessa. Tämä komentosarja on suoritettava tekstikonsolin ollessa aktiivinen, ja systemd suorittaa kaikki init-komentosarjat asynkronisesti, jolloin tämä komentosarja suoritetaan, kun X-palvelin on jo käynnissä. Tämän seurauksena konsolissa näytetään venäläisten kirjainten sijasta neliöitä, on mahdotonta vaihtaa asettelua ja vaihtaa takaisin graafiseen istuntoon.

Console-cyrillic on vanhentunut paketti, joka jäi järjestelmääni sen asennuksen jälkeen (eli Etch-päivinä). Tämä paketti on olemassa uudemmissa Debianin versioissa ja sitä tuetaan edelleen, mutta konsolin asennus- ja näppäimistön määrityspaketit ovat yleisempiä vaihtoehtoja. Artikkelissa Venäjän näyttäminen Ubuntu 11.04 Natty -konsolissa kuvataan niiden määrittämiseen tarvittavat vaiheet.

Asenna tarvittavat paketit:
# apt-get install console-setup keyboard-configuration Jos paketin konfiguraattori ei jostain syystä käynnistynyt paketteja asennettaessa, voit pakottaa paketin määrityksen:
# dpkg-reconfigure console-setup # dpkg-reconfigure keyboard-configuration Yleensä systemd tarjoaa uusia asetustiedostoja tekstikonsolin määrittämistä varten, mutta ne asetukset eivät toimineet järjestelmässäni.

2.2. Järjestelmän ajan tallentaminen BIOS-laitteistokelloon

Kun aika-asetuksia muutetaan, aika ei jostain syystä tallennu BIOS-kelloon. Voit tallentaa nykyisen järjestelmän ajan laitteistokelloon komennolla:
# hwclock -w Todellinen aika, joka tallennetaan BIOS-kelloon, riippuu tiedoston /etc/adjtime kolmannesta rivistä. UTC-merkkijonon tapauksessa Greenwichin keskiaika tallennetaan, LOCAL-merkkijonon tapauksessa nykyisen aikavyöhykkeen aika.

On huomattava, että Wheezyn jälkeen UTC-asetus on poistettu /etc/default/rcS-tiedostosta ja asetus /etc/adjtime: release-notes: utc/local timezone ei enää tiedostosta /etc/default/rcS. tiedostoa käytetään sen sijaan.

Ongelman syy on siinä, että käytän openntpd:tä, en ntpd:tä. Jos järjestelmäytimessä on käynnissä ntpd, nykyisen järjestelmän ajan tallentaminen laitteistoajastimeen sisältyy 11 minuutin välein. Systemdin kehittäjät katsoivat, että tämä riitti. Jos ntpd:tä ei käytetä, on mahdotonta määrittää, kumpi kelloista on tarkempi - laitteisto vai järjestelmä, joten ei ole mitään järkeä suosia yhtä kelloa toiseen verrattuna. Tarvittaessa käyttäjän on asetettava kello manuaalisesti tarpeen mukaan.

Tämän ongelman ratkaisemiseksi päätin kirjoittaa oman palvelutiedoston openntpd-daemonille. Palvelutiedoston /etc/systemd/system/openntpd.service sisältö:
Kuvaus=openntpd After=network.target Tyyppi=yksinkertainen ExecStart=/usr/sbin/ntpd -dsf /etc/openntpd/ntpd.conf ExecStartPost=/bin/chown ntpd /var/lib/openntpd/ntpd.drift ExecStop=/sbin /hwclock -w WantedBy=multi-user.target Nyt meidän on pysäytettävä jo käynnissä oleva openntpd-ilmentymä, kerrottava systemdille, että sen kokoonpano on muuttunut:
# systemctl stop openntpd.service # systemctl daemon-reload Lataa automaattisesti juuri luotu palvelutiedosto ja käynnistä openntpd:
# systemctl ota openntpd.service käyttöön # systemctl käynnistä openntpd.service 3. Palvelun hallinta

Systemd, toisin kuin inetd, voi valvoa itsenäisesti kaikkia palvelun luomia prosesseja. Tätä varten käytetään niin kutsuttuja prosessien ohjausryhmiä - c-ryhmiä. Jokainen palvelu alkaa omalla ryhmätunnuksellaan. Kaikki palvelun sisältämät lisäprosessit saavat myös tämän tunnisteen. Tämä poistaa tarpeen käyttää PID-tiedostoja palvelun hallintaan. Lisäksi cgroupsin ansiosta palvelun synnyttämät prosessit eivät koskaan katoa. Esimerkiksi CGI-prosessi pysäytetään verkkopalvelimen mukana, vaikka verkkopalvelin ei huolehtisi sen pysäyttämisestä ja laittaisi prosessin tunnuksen PID-tiedostoon. Käyttäjäprosessit on myös sijoitettu erilliseen ohjausryhmään, ja niitä valvoo sisäänkirjautumisalijärjestelmä, joka korvasi ConsoleKitin.

Toinen tärkeä systemd-ominaisuus on, että sillä on oma kirjausjärjestelmä nimeltä journald. Tämä järjestelmä kokoaa tietoa eri lähteistä ja sitoo ne palveluihin. Kokoaa ytimen viestit, prosessiviestit, jotka lähetetään syslogin kautta, viestit, jotka lähetetään journaldin alkuperäisellä API:lla, ja prosessin lähettämät viestit vakiolähtöön (STDOUT) ja diagnostisten viestien standardivirtaan (STDERR) yhteen paikkaan, joka on linkitetty palveluun. Systemd pitää kirjaa myös prosessin poistumiskoodeista. Tämän ansiosta kaikki palvelun diagnostiikkatiedot ovat nähtävissä yhdestä paikasta ja ongelmien diagnosointi on kätevää.

systemctl- tarkastella palveluiden tiloja. Jos komennon tulostetta ei ohjata jonnekin, vaan se pääsee konsoliin, hakuohjelma käynnistetään automaattisesti katsomaan palveluiden tilaa, yleensä se on pienempi,
systemctl-tila openntpd.service - yksityiskohtainen näkymä määritetyn palvelun tilasta (openntpd),
systemctl status --follow openntpd.service - tarkastelee määritetyn palvelun tilaa (openntpd) ja näyttää palvelun viestit niiden vastaanottamisen aikana. Tällä valinnalla on lyhyempi vastine -f, joka jostain syystä ei toiminut järjestelmässäni. Ehkä tosiasia on, että vaihtoehdolla -f on myös toinen merkitys - --force ja systemctl ei pysty määrittämään, mitä vaihtoehdoista tarkoitetaan,
systemctl status -n10 openntpd.service - tarkastella määritetyn palvelun tilaa (openntpd) palvelun 10 viimeisen viestin tulosteilla,
systemctl reset-failed- nollataan kaikki view service status -komennon näyttämät lopetustilat,
systemd-cgls- prosessinohjausryhmien hierarkian tarkastelu (jotain vastaavaa voidaan saada komennolla ps xawf -eo pid,user,cgroups,args),
systemctl daemon-reload- lataa järjestelmäkokoonpano uudelleen,
systemctl start openntpd.service - käynnistä määritetty palvelu (openntpd), kuten update-rc.d openntpd aloita SysV initd,
systemctl stop openntpd.service - lopeta määritetty palvelu (openntpd), kuten update-rc.d openntpd lopeta SysV initd,
systemctl uudelleenkäynnistys openntpd.service - käynnistä määritetty palvelu uudelleen (openntpd),
systemctl enable openntpd.service - ota käyttöön määritetyn palvelun (openntpd) käynnistys järjestelmän käynnistyksen yhteydessä, kuten update-rc.d openntpd ota käyttöön SysV initd,
systemctl pois käytöstä openntpd.service - poista määritetyn palvelun (openntpd) käynnistäminen käytöstä järjestelmän käynnistyksen yhteydessä, kuten update-rc.d openntpd poista käytöstä SysV initd:lle,
systemctl maski openntpd.service - määritetyn palvelun (openntpd) käynnistämisen kielto, sen käynnistäminen manuaalisesti on jopa mahdotonta,
systemctl paljastaa openntpd.service - oikeus käynnistää määritetty palvelu (openntpd), se voidaan käynnistää manuaalisesti, se saa myös käynnistyä järjestelmän käynnistyksen yhteydessä, jos se on määritetty,
systemctl kill openntpd.service - lähettää signaalin (oletusarvoisesti SIGTERM-signaali lähetetään) kaikille palvelun ohjausryhmän prosesseille (openntpd),
systemctl kill -s SIGKILL openntpd.service - lähettää SIGKILL-signaalin kaikille palvelun ohjausryhmän (openntpd) prosesseille. Voit myös käyttää signaalin lyhennettä - KILL,
systemctl kill -s HUP --kill-who=main cron palvelu - SIGHUP-signaalin lähettäminen palvelun ohjausryhmän (crond) pääprosessille. Tämä esimerkki pakottaa crondin lukemaan asetustiedoston uudelleen, kun taas crondin aloittamat työt eivät vastaanota tätä signaalia ja jatkavat toimintaansa normaalisti.
systemctl apua openntpd.service - tarkastella palveludokumentaatiota (ei toimi Debian Wheezyssä),
systemd-analyze syyttää- näyttää palveluluettelon, joka on lajiteltu niiden alkamisajan mukaan laskevaan järjestykseen. Komento voi olla hyödyllinen pullonkaulojen etsimisessä järjestelmän alustuksen aikana,
systemd-analyze plot > plot.svg- SVG-muodossa olevan ajoituskaavion tulostus, joka havainnollistaa palvelujen aloitusjärjestystä (ja rinnakkaisuutta).

4. Uudet järjestelmän asetustiedostot

Systemd esittelee useita uusia kokoonpanotiedostoja koko järjestelmän asetuksille. On odotettavissa, että näistä tiedostoista tulee lopulta standardeja ja ne korvaavat eri jakeluille ominaiset järjestelmän määritystiedostot. Kunnes näin tapahtuu, systemd käyttää jakelun määritystiedostoja, jos uusia tiedostoja ei ole.

Lisäksi, koska kaikki palvelut käynnistetään nyt palvelutiedostoilla, komentotulkkikomentosarjojen sisältämiä tiedostoja ei tarvitse käyttää. Nämä ovat tiedostoja, jotka sijaitsevat kansioissa /etc/default (Debian-perhe) ja /etc/sysconfig (RedHat-perhe). Koska palvelutiedostoissa on paljon helpompi navigoida kuin shell-skripteissä, palveluasetuksia ei tarvitse siirtää erillisiin tiedostoihin - kaikki tarvittavat asetukset voidaan syöttää suoraan palvelutiedostoon.

Tässä ovat systemd:n ​​uudet määritystiedostot:

/etc/isäntänimi- järjestelmän verkon nimi,
/etc/vconsole.conf- järjestelmäkonsolin fontti- ja näppäimistöasetteluasetukset,
/etc/locale.conf- järjestelmän kieliasetukset,
/etc/modules-load.d/*.conf- hakemisto, jossa luetellaan ytimen moduulit, jotka pakotetaan latautumaan järjestelmän käynnistyksen yhteydessä,
/etc/sysctl.d/*.conf- ytimen parametrien asetushakemisto, täydentää klassista /etc/sysctl.conf-tiedostoa,
/etc/tmpfiles.d/*.conf- hakemisto väliaikaisten tiedostoasetusten hallintaan,
/etc/binfmt.d/*.conf- hakemisto suoritettavien tiedostomuotojen, kuten Java-, Mono-, WINE-muotojen, rekisteröintiä varten,
/etc/os-release- tiedosto, jossa on jakelun tunniste ja sen versio,
/etc/machie-id- tiedosto, jossa on pysyvä yksilöllinen järjestelmätunniste,
/etc/machie-info- tiedosto, jossa on kuvaava verkkonimi järjestelmää varten. Järjestelmäkuvake, joka näytetään graafisissa kuorissa, on myös määritetty täällä. Tiedostoa palvelee systemd-hostnamed-daemon.

5. lokikirjauksen alijärjestelmä

Kuten jo mainittiin, systemd esittelee uuden lokijärjestelmän, joka kerää tietoa eri lähteistä (ytimen viestit, syslogiin lähetetyt viestit, STDOUT ja STDERR) yhteen paikkaan. Tämä järjestelmä ei pakota sinua hylkäämään tavallista syslog-lokidaemonia - voit käyttää molempia lokijärjestelmiä rinnakkain.

Journald käyttää kahta hakemistoa päiväkirjatietojen tallentamiseen:
/run/log/journal- hakemisto viimeaikaisten viestien soittopuskurilla,
/var/log/journal- hakemisto, jossa kaikki viestit pysyvästi tallennetaan.

Oletusarvoisesti käytetään vain ensimmäistä hakemistoa, ja kaikkien viestien jatkuvan tallennuksen mahdollistamiseksi toinen hakemisto on luotava manuaalisesti (Debian Wheezyssä tämä hakemisto luodaan automaattisesti, kun systemd asennetaan, eikä ensimmäistä hakemistoa käytetä):
# mkdir -p /var/log/journald Voit sitten poistaa oletusarvoisen rsyslog- tai ng-syslog-päiväkirjadaemonin, mutta sinun ei tarvitse poistaa sitä.

Debian Wheezyn kirjatut daemon-asetukset tallennetaan tiedostoon /etc/systemd/systemd-journald.conf. Siellä voit määrittää erityisesti lokitiedoston pakkausasetukset, rajoittaa lokitiedostojen kokoa, määrittää viestien monistamisen järjestelmäkonsoliin tai syslog-daemonille.

Pääkäyttäjällä ja adm-ryhmän käyttäjillä on pääsy kaikkiin lokin viesteihin, kun taas tavallisilla käyttäjillä on pääsy vain heidän prosessiensa luomiin viesteihin.

Voit tarkastella päiväkirjaviestejä Debian Wheezyssä käyttämällä systemd-journalctl-komentoa (käsikirja määrittää journalctl-komennon):
systemd-journalctl- katso kaikki viestit. Kuten systemctl:n tapauksessa, jos komennon ulostuloa ei ohjata minnekään, vaan se pääsee konsoliin, hakuohjelma käynnistetään automaattisesti helpottamaan viestien katselua, yleensä vähemmän,
systemd-journalctl -f- viestien katselu niiden vastaanottamisen aikana,
systemd-journalctl -n10- katso viimeiset 10 viestiä,
systemd-journalctl -b- tarkastella järjestelmän käynnistyksen jälkeen luotuja viestejä (ei toimi Debian Wheezyssä),
systemd-journalctl -b -p err- tarkastella viestejä, jotka on luotu järjestelmän käynnistyksen jälkeen ja joissa on prioriteettivirhe tai korkeampi (ei toimi Debian Wheezyssä),
systemd-journalctl -- since=yesterday- tarkastella kaikkia eilisen jälkeen luotuja viestejä (ei toimi Debian Wheezyssä),
systemd-journalctl --since=2012-10-15 --until="2012-10-16 23:59:59"- tarkastella kaikkia 15. ja 16. lokakuuta 2012 luotuja viestejä (ei toimi Debian Wheezyssä),
systemd-journalctl -u httpd --since=00:00 --until=09:30- tarkastella kaikkia viestejä, jotka httpd-käyttäjä on luonut tänään keskiyöstä puoleen yhdeksään (ei toimi Debian Wheezyssä),
systemd-journalctl /dev/sdc- tarkastella kaikkia viestejä, joissa mainitaan sdc-asema (ei toimi Debian Wheezyssä),
systemd-journalctl /usr/sbin/vpnc- tarkastella kaikkia viestejä /usr/sbin/vpnc-prosesseista (ei toimi Debian Wheezyssä),
systemd-journalctl /usr/sbin/vpnc /usr/sbin/dhclient- tarkastella kaikkia viestejä prosesseista /usr/sbin/vpnc ja /usr/sbin/dhclient, yhdistetty ja lajiteltu ajan mukaan (ei toimi Debian Wheezyssä),

Pelkän tekstiviestien katselun lisäksi on mahdollista tarkastella metatietoja, jotka päiväkirja itse lisää jokaiseen päiväkirjakirjaukseen. Näet nämä kentät käyttämällä seuraavaa vaihtoehtoa, joka vaihtaa tietojen tulostusmuotoa:
systemd-journalctl -o monisanainen- Näyttää kaikki viestin mukana tulevat metatiedot ihmisen luettavassa muodossa lokin viestin kanssa. Muut käytettävissä olevat muodot: vienti - sama monisanainen muoto, mutta ilman sisennyksiä, json - tuloste JSON-muodossa, cat - tulosta vain viestin teksti ilman lisätietoja.

Alaviivalla alkavia kenttien nimiä voidaan käyttää viestien suodattamiseen. Päiväkirja on indeksoitu kaikilla kentillä, joten haku on nopeaa. Esimerkkejä viestien suodattamisesta metatietojen perusteella:
systemd-journalctl _UID=70- näyttää kaikki käyttäjäprosessien viestit ID 70:llä,
systemd-journalctl _UID=70 _UID=71- kaikkien viestien tulostus käyttäjäprosesseista tunnisteilla 70 ja 71. Samannimisten kenttien määrittäminen edellyttää automaattisesti loogista TAI-toimintoa,
systemd-journalctl _HOSTNAME=epsilon _COMM=avahi-daemon- tulostaa kaikki viestit prosesseista nimeltä avahi-daemon, jotka toimivat epsilon-nimisessä tietokoneessa. Tässä tapauksessa määritetään eri kentät, joten looginen JA-operaatio tarkoittaa,
systemd-journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon- näyttää viestit, jotka vastaavat mitä tahansa kahdesta suodattimesta yhdistettynä +-merkkiin. +-merkki ilmaisee eksplisiittistä loogista TAI-toimintoa, jolla on pienempi prioriteetti kuin JA,
systemd-journalctl -F _SYSTEMD_UNIT- kaikkien lokissa saatavilla olevien _SYSTEMD_UNIT-kentän arvojen tulostus. Saatuja arvoja voidaan käyttää kiinnostavien tietueiden suodattamiseen (ei toimi Debian Wheezyssä).

Minulla kesti toissapäivänä kirjoittaa yksinkertaisen bash-komentosarjan valvoakseni jatkuvasti hakemiston *.pdf-tiedostojen esiintymistä siinä ja niiden muuntamista txt-muotoon. Skriptin piti toimia taustalla ja käynnistyä automaattisesti uudelleenkäynnistyksen yhteydessä.

Taustatyön toteuttamiseksi kirjoitin ensin Linuxin - demoni C-kielellä, mutta sitten päätin, että tämä oli liikaa tehtävääni, ja toteutin sen Systemdillä.

Ensin sinun on varmistettava, että jakelusi toimii Systemdin kanssa komennolla:

luelinkki /proc/1/exe
jos lähtö on /sbin/init- silloin käytät SysV:tä ja sinun on joko päivitettävä jakelu, kuten minun tapauksessani päivitin Debian 7 Wheezy -version Debian 8 Jessieksi, tai toteuttaa taustatyö jollain muulla tavalla.

Jos tulos on:
/lib/systemd/systemd- silloin kaikki on kunnossa, sinulla on Systemd.

Systemd tekee työnsä niin kutsuttujen systemd-yksiköiden kanssa.
Yksikkö on konfiguraatiotiedosto, joka sijaitsee yhdessä hakemistoista:

/run/systemd/system/- Suorituksen aikana luodut yksiköt. Tällä hakemistolla on etusija paketeista asennettuja yksiköitä sisältävään hakemistoon nähden.
/etc/systemd/system/- järjestelmänvalvojan luomat ja hallinnoimat yksiköt. Tämä hakemisto on etusijalla suorituksen aikana luotujen yksiköiden hakemistoon nähden. Tässä hakemistossa luomme yksikkömme.

Menemme hakemistoon /etc/systemd/system/ ja luomme sen tai kopioimme olemassa olevan tiedoston, esimerkiksi sshd.service, ja kirjoitamme siihen:

[Yksikkö]

Description=MyBashScript

After=syslog.target

1. [Palvelu]

2. ExecStart=/bin/bash "/home/user/scripts/script.sh"

   Tyyppi = haarukka

3. [Asentaa]

   WantedBy=multi-user.target

   Alias=bash.service

Lisätietoja kustakin osiosta:
Osasto:
Sisältää yleistä tietoa palvelusta, sen kuvauksesta ja siitä, että sen pitäisi käynnistyä, kun Syslog-daemon on käynnissä.

osio
Suoraa tietoa palvelustamme.
ExecStart-parametri osoittaa palvelumme suoritettavaan tiedostoon. Sinun on määritettävä absoluuttiset polut, bash-skriptin tapauksessa käytämme skriptin polkua yksittäisissä lainausmerkeissä.
Type=forking tarkoittaa, että suoritettava komentosarja toimii demonitilassa. Jos haluamme, että komentosarja suoritetaan kerran, määritämme Type=simple.

osio
Viimeisessä osiossa on tietoja kohteesta, josta palvelun tulisi käynnistyä. Tässä tapauksessa haluamme palvelun käynnistyvän, kun multi-user.target aktivoidaan (tämä vastaa SysV:n init 3:ta).
Alias=bash.service - luodaan mukavuuden vuoksi alias, joka helpottaa palvelumme hallintaa systemctl:n kautta.

Tämä on toimiva Systemd-palvelutiedosto, jolla on vain vähän toimintoja. Tallenna tiedosto ja suorita komento systemctl daemon-reload jotta Systemd tietää palvelustamme ja voit käynnistää sen komennolla systemctl käynnistä bash.service.
Se ei toiminut minulle ensimmäisellä kerralla, koska ensin määritin ei-absoluuttisen polun osan ExecStart-parametrissa. Korjauksen jälkeen Systemd valitti edelleen samasta virheestä, uudelleenkäynnistys auttoi.

Voit tarkastella tilaa, käynnistää, pysäyttää, käynnistää uudelleen, ottaa käyttöön tai poistaa käytöstä järjestelmäpalvelut käyttämällä komentoa systemctl. Systemdin aikaisemmat versiot käyttivät service- ja chkconfig-komentoja, ja ne sisältyvät edelleen järjestelmään pääasiassa taaksepäin yhteensopivuuden vuoksi.

Alla ovat tärkeimmät systemctl-komennot:

systemctl start name.service-huollon aloitus.
systemctl stop name.service-huoltopysäkki
systemctl uudelleenkäynnistys name.service- palvelun uudelleenkäynnistys
systemctl try-restart name.service- käynnistä palvelu uudelleen vain, jos se on käynnissä
systemctl lataa nimi.palvelu- Palvelukokoonpanon uudelleenlataus
systemctl-tila nimi.palvelu- Tarkista, onko palvelu käynnissä yksityiskohtaisella palvelun tilatulosteella
systemctl on-aktiivinen nimi.palvelu- Tarkista, toimiiko palvelu yksinkertaisella vastauksella: aktiivinen vai ei-aktiivinen
systemctl list-units --type service --all– näyttää kaikkien palveluiden tilan
systemctl enable name.service– aktivoi palvelun (sallii sen käynnistymisen järjestelmän käynnistyksen aikana)
systemctl poista nimi.palvelu käytöstä- deaktivoi palvelu
systemctl ottaa uudelleen käyttöön name.service– poistaa palvelun käytöstä ja aktivoi sen välittömästi
systemctl is-enabled name.service- tarkistaa, onko palvelu aktivoitu
systemctl list-unit-files --tyyppipalvelu– näyttää kaikki palvelut ja tarkistaa, mitkä niistä on aktivoitu
systemctl mask name.service- korvaa palvelutiedoston symbolin linkillä hakemistoon /dev/null, jolloin järjestelmä ei pääse yksikköön
systemctl unmask name.service- palauttaa huoltotiedoston, jolloin laite on systemd:n ​​käytettävissä

Systemd on aloitusjärjestelmä ja järjestelmänhallinta, josta on tulossa uusi standardi Linux-koneille. Keskustelu systemd:n ​​suorituskyvystä verrattuna perinteisiin SysV-init-järjestelmiin jatkuu edelleen, mutta useimmat jakelut suunnittelevat tämän järjestelmän käyttöönottoa, ja monet ovat jo tehneet niin.

Systemd:n ​​työkalujen ja demonien oppiminen ja niiden käyttäminen auttaa sinua ymmärtämään paremmin järjestelmän tehoa, joustavuutta ja muita ominaisuuksia tai ainakin selviytymään minimaalisesta vaivasta.

Tämä opetusohjelma opettaa sinua käyttämään systemctl-komentoa, joka on systemd init -järjestelmän tärkein hallintatyökalu. Opit hallitsemaan palveluita, tarkistamaan tilan ja työskentelemään asetustiedostojen kanssa.

Palvelujen hallinta

Init-järjestelmän päätarkoitus on alustaa komponentit, jotka tulisi käynnistää Linux-ytimen latauksen jälkeen (kutsutaan perinteisesti "muokatuiksi" komponenteiksi). Init-järjestelmää käytetään myös palvelinpalvelujen ja demonien hallintaan. Tätä silmällä pitäen aloitetaan systemd-esittely yksinkertaisilla palvelunhallintatoiminnoilla.

Systemd:ssä useimpien toimintojen kohteena ovat yksiköt, jotka ovat resursseja, joita systemd voi hallita. Yksiköt luokitellaan niiden edustamien resurssien tyyppien mukaan. Yksiköt määritellään ns. yksikkötiedostoissa. Kunkin yksikön tyyppi voidaan määrittää tiedoston lopussa olevalla päätteellä.

Yksikkötiedostot, joissa on .service-liite, on tarkoitettu palvelunhallintatehtäviin. Useimmissa tapauksissa .service-liite voidaan kuitenkin jättää pois, koska systemd on tarpeeksi älykäs selvittääkseen, mitä tehdä käytettäessä palvelun ohjauskomentoja ilman päätettä.

Palvelun käynnistäminen ja lopettaminen

Käynnistä systemd-palvelu käyttämällä start-komentoa. Jos et ole juuri-istunnossa, sinun on käytettävä sudoa, koska tämä komento vaikuttaa käyttöjärjestelmän tilaan:

sudo systemctl start application.service

Kuten aiemmin mainittiin, systemd osaa etsiä *.service-tiedostoja palvelunhallintakomentoja varten, joten tämä komento voidaan kirjoittaa seuraavasti:

sudo systemctl käynnistä sovellus

Yllä olevaa muotoa voidaan käyttää jokapäiväisessä työssä, mutta käsikirjassa käytämme selvyyden vuoksi .service-liitettä.

Pysäytä palvelu kirjoittamalla stop-komento:

sudo systemctl stop application.service

Käynnistä uudelleen ja käynnistä uudelleen

Käynnistä palvelu uudelleen käyttämällä uudelleenkäynnistystä:

sudo systemctl käynnistä application.service uudelleen

Jos määritetty sovellus voi ladata määritystiedostonsa uudelleen (ilman uudelleenkäynnistystä), uudelleenlatausta voidaan käyttää:

sudo systemctl lataa application.service

Jos et tiedä, voiko palvelu ladata tiedostonsa uudelleen, käytä reload-or-restart-komentoa. Se käynnistää palvelun uudelleen, ja jos tämä ei ole mahdollista, se käynnistää sen uudelleen.

sudo systemctl reload-or-restart application.service

Palvelujen käyttöönotto ja poistaminen käytöstä

Yllä olevat komennot vaaditaan työskennellessäsi palvelun kanssa nykyisessä istunnossa. Jos haluat lisätä palvelun systemd autoloadiin, sinun on otettava se käyttöön.

Tätä varten on käytössä komento:

sudo systemctl enable application.service

Tämä luo symbolisen linkin palvelutiedoston kopioon (yleensä tiedostossa /lib/systemd/system tai /etc/systemd/system) siihen kohtaan levylle, josta systemd etsii automaattisesti käynnistyviä tiedostoja (yleensä /etc/systemd/system /some_target.target.want , tästä lisää myöhemmin oppaassa).

Jos haluat poistaa palvelun käynnistyksestä, sinun on annettava:

sudo systemctl poista application.service käytöstä

Muista, että palvelun käyttöönotto ei käynnistä sitä nykyisessä istunnossa. Jos haluat käynnistää palvelun ja sisällyttää sen käynnistykseen, sinun on suoritettava käynnistys- ja käyttöönottokomennot.

Palvelun tilan tarkistaminen

Voit tarkistaa palvelun tilan kirjoittamalla:

systemctl status application.service

Tämä komento tulostaa palvelun tilan, ryhmähierarkian ja lokin muutaman ensimmäisen rivin.

Esimerkiksi, kun tarkistat Nginx-palvelimen tilan, saatat nähdä seuraavanlaisen lähdön:

nginx.service - Tehokas verkkopalvelin ja käänteinen välityspalvelin
Ladattu: ladattu (/usr/lib/systemd/system/nginx.service; käytössä; toimittajan esiasetus: poistettu käytöstä)
Aktiivinen: aktiivinen (juoksu) alkaen ti 2015-01-27 19:41:23 EST; 22 tuntia sitten
Pää-PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: pääprosessi /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: työntekijäprosessi
27. tammikuuta 19:41:23 desktop systemd: Käynnistetään Tehokas web-palvelin ja käänteinen välityspalvelin...
27. tammikuuta 19:41:23 desktop systemd: Aloitettu Tehokas web-palvelin ja käänteinen välityspalvelin.

Tämä antaa yleiskatsauksen sovelluksen nykytilasta, ilmoittaa kaikista ongelmista ja toimenpiteistä, joita voidaan tarvita tulevaisuudessa.

On myös menetelmiä tiettyjen tilojen tarkistamiseen. Voit esimerkiksi tarkistaa, onko tietty yksikkö aktiivinen (käynnissä), käyttämällä is-active -komentoa:

systemctl on-active application.service

Tämä näyttää laitteen nykyisen tilan, yleensä aktiivisena tai ei-aktiivisena. Poistumiskoodi on "0", jos yksikkö on aktiivinen, mikä yksinkertaistaa analyysiprosessia.

Jos haluat selvittää, onko yksikkö käytössä, voit käyttää is-enabled-komentoa:

systemctl is-enabled application.service

Tämä komento ilmoittaa, onko palvelu käytössä, ja palauttaa poistumiskoodin "0" tai "1" tuloksesta riippuen.

Kolmannen komennon avulla voit määrittää, onko laite viallisessa tilassa. Tämä osoittaa, että kyseessä olevan yksikön käynnistyksessä oli ongelma:

systemctl is-failed application.service

Komento palautuu aktiiviseksi, jos laite toimii oikein, ja epäonnistuu, jos on tapahtunut virhe. Jos yksikkö pysäytettiin tarkoituksella, komento voi palauttaa tuntemattoman tai epäaktiivisen. Poistumiskoodi "0" tarkoittaa, että on tapahtunut vika, kun taas "1" tarkoittaa mitä tahansa muuta tilaa.

Yleiskatsaus järjestelmän tilasta

Aiemmin käsiteltiin yksittäisten palveluiden hallintaan tarvittavia komentoja, mutta ne eivät ole kovin hyödyllisiä järjestelmän nykytilan tarkastelussa. On olemassa useita systemctl-komentoja, jotka tarjoavat nämä tiedot.

Nykyisten yksiköiden luettelon tarkasteleminen

Voit pyytää luetteloa nykyisistä systemd-yksiköistä käyttämällä list-units-komentoa:

systemctl listayksiköt

Tämä komento listaa kaikki systemd-järjestelmässä tällä hetkellä olevat yksiköt. Tulos näyttää suunnilleen tältä:

YKSIKKÖKUORMA AKTIIVINEN SUB KUVAUS
atd.service ladattu aktiivisesti käynnissä oleva ATD-daemon
avahi-daemon.service ladattu aktiivisesti käynnissä Avahi mDNS/DNS-SD Stack
dbus.service ladattu aktiivisesti käynnissä D-Bus System Message Bus
dcron.service ladattu aktiivisesti käynnissä Periodic Command Scheduler
dkms.service ladattu aktiivinen poistui Dynamic Kernel Modules System -järjestelmästä
[sähköposti suojattu] ladattu aktiivinen käynnissä Getty on tty1
. . .

Tulosteessa on seuraavat sarakkeet:

• UNIT on systemd-yksikön nimi.
• LOAD Kertoo, onko systemd käsitellyt yksikön asetukset. Ladattujen yksiköiden konfiguraatio tallennetaan muistiin.
• ACTIVE - yksikön yhteenvetotila. Tämän avulla voit yleensä nopeasti määrittää, onko nykyinen yksikkö käynnistynyt onnistuneesti.
• SUB: Alatason tila, joka tarjoaa yksityiskohtaista tietoa laitteesta. Tämä riippuu usein yksikön tyypistä, tilasta ja todellisesta menetelmästä, jolla yksikkö toimii.
• KUVAUS - lyhyt kuvaus laitteen toiminnoista.

Koska list-units-komento näyttää oletusarvoisesti vain aktiiviset yksiköt, kaikki yllä olevat merkinnät näkyvät ladattuina LOAD-sarakkeessa ja aktiivisena ACTIVE-sarakkeessa. Tämä muoto on systemctl:n oletuskäyttäytyminen, kun sitä kutsutaan ilman lisäkomentoja, joten näet saman asian, jos kutsut systemctl:tä ilman argumentteja:

Systemctl:llä voit kysyä erilaisia ​​tietoja lisäämällä lippuja. Voit esimerkiksi nähdä kaikki yksiköt, jotka systemd on ladannut (tai yrittänyt ladata), olivatpa ne tällä hetkellä aktiivisia vai eivät, voit käyttää -all-lippua:

systemctl list-units --all

Tämä komento raportoi yksiköt, jotka systemd on ladannut tai yrittänyt ladata niiden nykyisestä tilasta riippumatta. Käynnistyksen jälkeen jotkut yksiköt muuttuvat passiivisiksi, eikä yksiköitä, joita järjestelmä yritti ladata, ei löytynyt levyltä.

Voit käyttää muita lippuja tulosten suodattamiseen. Esimerkiksi lippua --state= voidaan käyttää LOAD-, ACTIVE- tai SUB-tilojen määrittämiseen. --all -lippu on jätettävä, jotta järjestelmä näyttää ei-aktiiviset yksiköt:

systemctl list-units --all --state=inactive

Toinen suosittu suodatin on --type=. Sen avulla voit suodattaa yksiköitä tyypin mukaan. Jos esimerkiksi haluat pyytää vain aktiivisia yksiköitä, voit kirjoittaa:

systemctl list-units --type=service

Luettelo yksikkötiedostoista

List-units-komento listaa vain ne yksiköt, jotka systemd on yrittänyt käsitellä ja ladata muistiin. Koska systemd lukee valikoivasti vain ne yksikkötiedostot, jotka se uskoo tarvitsevansa, luettelo ei sisällä kaikkia saatavilla olevia yksikkötiedostoja. Listaa kaikki käytettävissä olevat yksikkötiedostot (mukaan lukien ne, joita systemd ei yrittänyt ladata), käytä komentoa list-unit-files.

systemctl lista-yksikkö-tiedostot

Yksiköt ovat esityksiä resursseista, joista järjestelmä tietää. Koska systemd ei välttämättä lue kaikkia yksikkömäärityksiä, se näyttää vain tiedot itse tiedostoista. Tulos koostuu kahdesta sarakkeesta: UNIT FILE ja STATE.

YKSIKKÖTIEDOSTON TILA
proc-sys-fs-binfmt_misc.automount staattinen
dev-hugepages.mount static
dev-mqueue.mount staattinen
proc-fs-nfsd.mount staattinen
proc-sys-fs-binfmt_misc.mount staattinen
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount staattinen
var-lib-nfs-rpc_pipefs.mount staattinen
org.cups.cupsd.path käytössä
. . .

Tyypillisesti STATE-sarake sisältää arvot käytössä, pois käytöstä, staattinen tai peitetty. Tässä yhteydessä staattinen tarkoittaa, että yksikkötiedostossa ei ole asennusosaa, jota käytetään yksikön käyttöönottoon. Siksi näitä yksiköitä ei voi ottaa käyttöön. Tämä tarkoittaa yleensä sitä, että yksikkö suorittaa kertaluonteisen toiminnon tai sitä käytetään vain riippuvaisena toisesta yksiköstä, eikä sitä tule käynnistää itsestään.

Yksikön hallinta

Nyt osaat työskennellä palveluiden kanssa ja näyttää tietoja yksiköistä ja yksikkötiedostoista, joista systemd tietää. Voit saada tarkempia tietoja yksiköistä käyttämällä joitain lisäkomentoja.

Yksikkötiedoston näyttö

Voit näyttää systemd:n ​​lataaman yksikkötiedoston käyttämällä cat-komentoa (lisätty systemd-versioon 209). Voit esimerkiksi tarkastella atd-aikataulutusdaemon-yksikkötiedostoa kirjoittamalla:

systemctl cat atd.service
Kuvaus=ATD-daemon
Tyyppi = haarukka
ExecStart=/usr/bin/atd
WantedBy=multi-user.target

Näytöllä näet yksikkötiedoston, jonka parhaillaan käynnissä oleva systemd-prosessi tuntee. Tämä voi olla tärkeää, jos olet muuttanut yksikkötiedostojasi äskettäin tai jos olet määrittämässä uudelleen joitakin yksikkötiedostojen asetuksia (lisätietoja myöhemmin).

Riippuvuuksien kartoitus

Voit tarkastella yksikön riippuvuuspuuta käyttämällä komentoa:

systemctl list-dependencies sshd.service

Se näyttää hierarkian riippuvuuksista, joita järjestelmän on käsiteltävä voidakseen käyttää tätä yksikköä. Riippuvuudet ovat tässä yhteydessä ne yksiköt, joita tarvitaan muiden hierarkiassa ylempänä olevien yksiköiden toimintaan.

sshd.service
├─system.slice
└─perus.kohde
├─mikrokoodi.palvelu
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─polut.kohde
├─slices.target
. . .

Rekursiiviset riippuvuudet näytetään vain .target-yksiköille, jotka osoittavat järjestelmän tilat. Listaa kaikki riippuvuudet rekursiivisesti lisäämällä --all-lippu.

Jos haluat näyttää käänteiset riippuvuudet (yksiköt, jotka riippuvat määritetystä elementistä), voit lisätä komentoon --reverse-lipun. --before- ja --aff-liput ovat myös hyödyllisiä, ne näyttävät yksiköt, jotka riippuvat määritetystä yksiköstä ja toimivat ennen tai jälkeen sitä.

Yksikön ominaisuuksien tarkistus

Jos haluat nähdä yksikön matalan tason ominaisuudet, voit käyttää show-komentoa. Tämä näyttää luettelon määritetyn yksikön ominaisuuksista muodossa avain=arvo.

systemctl näyttää sshd.service
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Konfliktit=shutdown.target
Before=shutdown.target usean käyttäjän.kohde
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH-palvelimen demoni
. . .

Jos haluat näyttää jonkin ominaisuuksista, välitä -p-lippu ja määritä ominaisuuden nimi. Jos esimerkiksi haluat nähdä ristiriidat yksikössä sshd.service, kirjoitat:

systemctl show sshd.service -p Ristiriidat
Konfliktit=shutdown.target

Yksikön naamio

Systemd voi lukita yksikön (automaattisesti tai manuaalisesti) luomalla symlinkin hakemistoon /dev/null. Tätä kutsutaan yksikön peittämiseksi ja se tehdään mask-komennolla:

sudo systemctl mask nginx.service

Nyt Nginx-palvelu ei käynnisty automaattisesti tai manuaalisesti niin kauan kuin naamiointi on käytössä.

Jos tarkistat lista-yksikkötiedostot, näet, että palvelu on merkitty peitetyksi:

systemctl lista-yksikkö-tiedostot
. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service staattinen
nginx.service masked
quotaon.service staattinen
rc-local.service static
rdisc.service poistettu käytöstä
pelastuspalvelu staattinen
. . .

Jos yrität käynnistää palvelun, saat tämän viestin:

sudo systemctl käynnistä nginx.service
Palvelun nginx.service käynnistys epäonnistui: Yksikkö nginx.service on peitetty.

Voit paljastaa yksikön ja asettaa sen saataville käyttämällä unmask-toimintoa:

sudo systemctl unmask nginx.service

Tämä palauttaa palvelun aiempaan tilaan.

Yksikkötiedostojen muokkaaminen

Vaikka yksikkötiedostojen erityistä muotoa ei käsitellä tässä oppaassa, systemctl tarjoaa sisäänrakennetut mekanismit yksikkötiedostojen muokkaamiseen ja muokkaamiseen. Tämä toiminto lisättiin systemd-versioon 218.

Edit-komento avaa oletusarvoisesti yksikkötiedoston katkelman:

sudo systemctl muokkaa nginx.service

Tämä on tyhjä tiedosto, jota voidaan käyttää ohittamaan tai lisäämään käskyjä yksikkömääritykseen. /etc/systemd/system-hakemistoon luodaan hakemisto, joka sisältää laitteen nimen .d-liitteellä. Esimerkiksi nginx.servicelle luodaan hakemisto nginx.service.d.

Tämän hakemiston sisään luodaan katkelma nimeltä override.conf. Kun yksikkö on ladattu, systemd yhdistää muistissa olevan ohituskoodinpätkän muuhun yksikkötiedostoon. Katkelmakäskyt ovat ensisijaisia ​​lähdeyksikkötiedostossa määritettyihin nähden.

Jos haluat muokata koko yksikkötiedostoa katkelman luomisen sijaan, voit välittää --full-lipun:

sudo systemctl muokkaa --full nginx.service

Tämä lataa nykyisen yksikkötiedoston editoriin, jossa sitä voidaan muokata. Kun editori sulkeutuu, muokattu tiedosto kirjoitetaan hakemistoon /etc/systemd/system ja se on etusijalla järjestelmäyksikön määrittelyyn nähden (sijaitsee yleensä jossain hakemistossa /lib/systemd/system).

Jos haluat poistaa tekemäsi lisäykset, poista config.d-hakemisto tai muokattu palvelutiedosto tiedostosta /etc/systemd/system. Voit esimerkiksi poistaa katkelman kirjoittamalla:

sudo rm -r /etc/systemd/system/nginx.service.d

Jos haluat poistaa koko muokatun tiedoston, kirjoita:

sudo rm /etc/systemd/system/nginx.service

Tiedoston tai hakemiston poistamisen jälkeen systemd-prosessi on ladattava uudelleen, jotta järjestelmä ei enää yritä viitata näihin tiedostoihin ja palaa käyttämään järjestelmäkopioita. Voit tehdä tämän kirjoittamalla:

sudo systemctl daemon-reload

Ajotasojen vaihtaminen

Kohteet ovat erityisiä yksikkötiedostoja, jotka kuvaavat järjestelmätasoja tai synkronointipisteitä. Kuten muutkin yksiköt, kohdetiedostot voidaan tunnistaa päätteellä. Tässä tapauksessa käytetään .target-liitettä. Kohteet eivät sinänsä tee mitään, vaan niitä käytetään muiden yksiköiden ryhmittelyyn.

Tavoitteita voidaan käyttää järjestelmän saattamiseksi tiettyyn tilaan. Vastaavasti muut init-järjestelmät käyttävät ajotasoja. Niitä käytetään viitteinä, kun tietyt ominaisuudet ovat saatavilla, jolloin voit määrittää halutun tilan sen sijaan, että määrität yksittäisiä yksiköitä, joita tarvitaan kyseisen tilan luomiseen.

Esimerkiksi on olemassa swap.target, jota käytetään osoittamaan, että swap on valmis käytettäväksi. Yksiköt, jotka ovat osa tätä prosessia, voidaan synkronoida tähän tarkoitukseen käyttämällä WantedBy=- tai RequiredBy=-käskyjä. Yksiköt, jotka tarvitsevat vaihdon, voivat määrittää tämän ehdon Wants=-, Requires=- tai After=-määrittelyillä.

Oletustavoitteiden tarkistaminen ja asettaminen

Systemd-prosessilla on oletuskohde, jota se käyttää järjestelmän käynnistyessä. Riippuvuusjoukon tarjoaminen tälle yksittäiselle kohteelle tuo järjestelmän haluttuun tilaan. Etsi oletuskohde kirjoittamalla:

systemctl get-default
monen käyttäjän.kohde

Jos haluat asettaa eri oletuskohteen, voit käyttää set-default-toimintoa. Jos sinulla on esimerkiksi graafinen työpöytä asennettuna ja haluat järjestelmän lataavan sen oletusarvoisesti, voit muuttaa kohdetta vastaavasti:

sudo systemctl set-default graphical.target

Luettelo käytettävissä olevista kohteista

Voit tarkastella käytettävissä olevien kohteiden luetteloa komennolla:

systemctl list-unit-files --type=target

Toisin kuin ajotasot, useita kohteita voidaan ottaa käyttöön samanaikaisesti. Aktiivinen kohde osoittaa, että systemd yrittää käynnistää kaikki kyseiseen kohteeseen sidotut yksiköt eikä yritä poistaa niitä käytöstä. Näet kaikki aktiiviset kohteet kirjoittamalla:

systemctl list-units --type=target

Tavoitteena oleva eristäminen

On mahdollista käynnistää kaikki kohteeseen liittyvät yksiköt ja pysäyttää kaikki yksiköt, jotka eivät ole osa riippuvuuspuuta. Isolate-komentoa käytetään tähän. Se on samanlainen kuin ajotason muuttaminen muissa aloitusjärjestelmissä.

Jos esimerkiksi työskentelet graafisessa ympäristössä, jossa graphical.target-kohde on aktiivinen, voit poistaa graafisen järjestelmän käytöstä ja asettaa järjestelmän usean käyttäjän komentorivitilaan eristämällä multi-user.target. Koska graphical.target riippuu monen käyttäjän.kohde -kohdasta, mutta ei päinvastoin, kaikki graafiset yksiköt pysäytetään.

Voit katsoa eristettävän kohteen riippuvuuksia ennen tämän toimenpiteen suorittamista varmistaaksesi, että et lopeta tärkeitä palveluita:

systemctl list-dependencies multi-user.target

Jos kaikki sopii sinulle, voit eristää kohteen:

sudo systemctl eristää multi-user.target

Lyhenteet

Tärkeille tapahtumille, kuten sammutukselle tai uudelleenkäynnistykselle, on määritetty tavoitteet. systemctl tarjoaa myös useita pikakuvakkeita nopeaa käyttöä varten.

Esimerkiksi, jos haluat laittaa järjestelmän virheenkorjaustilaan, voit syöttää toiminnon Rescue sen sijaan, että eristäisit pelastus.target:

sudo systemctl pelastus

Tämä tarjoaa lisätoimintoja - se ilmoittaa tapahtumasta kaikille järjestelmän käyttäjille.

Voit pysäyttää järjestelmän käyttämällä pysäytyskomentoa:

sudo systemctl stop

Voit käynnistää täyden sammutuksen käyttämällä poweroff-komentoa:

sudo systemctl poweroff

Uudelleenkäynnistys voidaan käynnistää reboot-komennolla:

sudo systemctl käynnistyy uudelleen

Nämä komennot ilmoittavat järjestelmän käyttäjille tapahtumista, joita vakiokomento ei tee. Huomaa, että useimmat koneet käyttävät lyhyempiä komentoja näihin toimintoihin, jotta ne toimivat oikein systemd:n ​​kanssa.

Voit esimerkiksi käynnistää järjestelmän uudelleen kirjoittamalla:

Johtopäätös

Nyt tunnet systemctl:n perusmekanismit ja osaat ohjata init-järjestelmää tällä työkalulla.

Vaikka systemctl toimii ensisijaisesti systemd-prosessin kanssa, systemd-järjestelmässä on muita komponentteja, joita muut apuohjelmat ohjaavat. Esimerkiksi erillisiä demoneja ja apuohjelmia käytetään loki- ja käyttäjäistuntojen hallintaan (journald/journalctl ja logind/loginctl, vastaavasti).