Jump to content
From ArchWiki

Aiheeseen liittyen

- systemd/User
- systemd/Timers
- systemd/Journal
- systemd FAQ
- init
- Daemons
- udev
- Improving performance/Boot process
- Allow users to shutdown

Lainattu ja suomennettu projektin sivulta:

  systemd on Linuxille luotu kokonaisuus systeemin peruspalikoista. Se tarjoaa järjestelmän ja palvelumanagerin ja toimii PID:llä 1 ja lähtee suorittamaan järjestelmän muita osasia. Systemd tarjoaa agressiivisen rinnastus kyvyn, käyttää socketin ja D-Bus aktivointia palvelujen käynnistämiseen, mahdollistaa tarvittaessa taustaprosessien käynnistämisen, pitää kirjaa prosesseista jotka käyttävät Linuxin control groups, ylläpitää mounttaus ja automounttaus paikkoja ja implementoi toiminallisen riippuvuuksiin perustuvan hallinta logiikan. systemd tukee SysV ja LSB:n init skriptejä ja alkujaan toimii korvaavana ratkaisuna sysvinitille. Toisaalta systemd:stä löytyy myös loggaus palveluprosessi, apuvälineitä hallitsemaan perus järjestelmän konfigurointia kuten verkkotunnus, päivämäärä,paikalliset asetukset, listattuna käyttäjien sisäänkirjautumiset ja käytetyt virtuaalikoneet, järjestelmä tilit, ajoajan järjestelmäpolut sekä asetukset ja taustaprosessit yksinkertaisille verkko konfiguraatioille, verkon ajan tahdistus, kirjauksien siirrot ja nimiresoluutio.

Huomautus: Perustelu miksi Arch siirtyi systemd:hen, lue tämä keskusteluviesti.

## Perus systemctl:n käyttö

Päällimmäinen komento jolla voidaan tutkiskella ja hallita systemd:tä on systemctl. Jotain hyötyjä tällä on järjestelmän tilan tutkiminen ja järjestelmän sekä palvelujen hallitseminen. Katso systemctl(1) löytääksesi enemmän tietoa liittyen sen käyttöön.

Vinkki:

- Voit käyttää kaikkia seuraavia systemctl komentoja käyttämällä `-H user@host` kytkintä hallitsemaan systemd instanssia etäkoneesta. Tämä käyttää SSH tunnelia yhdistämään etänä systemd instanssiin.
- Plasma:n alla on mahdollista asentaa systemd-kcmAUR graafisena tulkkina systemctl:lle. Asennuksen jälkeen moduuli löytyy System administration:in alta.

### Järjestelmävaiheen analysointi

Näet järjestelmän tilan komennolla:

    $ systemctl status

Listaa käynnistetyt yksiköt:

    $ systemctl

tai:

    $ systemctl list-units

Listaa kaatuneet yksiköt:

    $ systemctl --failed

Saatavilla olevat yksikkötiedostot (eng. unit file) ovat nähtävissä poluissa `/usr/lib/systemd/system/` ja `/etc/systemd/system/` (viimeineen vaatii oikeuksia polun lukemiseen). Listaa asennetut yksikkötiedostot komennolla:

    $ systemctl list-unit-files

Näytä cgroup slice, muisti ja isäntä PID:ille:

    $ systemctl status pid

### Yksiköiden käyttö

Yksiköitä voi olla esim. palvelut (.service), mounttaus paikat (.mount), laitteet (.device) tai socketit (.socket).

Kun systemctl:ää halutaan käyttää, joudut usein määrittelemään kokonaisuudessa koko yksikkötiedoston nimen, mukaanlukien sen loppuliitteen, esim. `sshd.socket`. Siitä huolimatta on olemassa muutamia lyhyitä muotoja kun tarkennetaan yksikköä kuten seuraavissa systemctl komennoissa on:

- Jos loppuliitettä ei tarkenneta, systemctl olettaa .service. Esim. `netctl` ja `netctl.service` tulkitaan samana.
- Mounttaus paikat automaattisesti käännetään oikeaan muotoon .mount yksikkö. Esim. antamalla `/home` on sama kuin `home.mount`.
- Samalla tavalla kuin mounttaus paikat, laitteet automaattisesti käännetään muotoon .device yksikkö, siksipä antamalla `/dev/sda2` on sama kuin `dev-sda2.device`.

Löydät aiheesta yksityiskohtaisesti systemd.unit(5).

Huomautus: Jotkin yksikkö nimet sisältävät `@` merkin (esim. muotoa `name@string.service`): tällöin nämä ovat instansseja template yksiköstä, minkä todellinen tiedosto nimi ei sisällä `string` osaa (esim. muotoa `name@.service`). `string` on mitä kutsutaan instanssi tunnisteeksi, ja on samanlainen komennon kanssa joka annetaan template yksikölle kun sitä kutsutaan systemctl komennolla: yksikkötiedostossa se korvautuu `%i` tarkenteella. Tarkemmin sanottuna, ennen kuin systemd yrittää toteuttaa `name@.suffix` template yksikön, se yrittää etsiä yksikköä samalla `name@string.suffix` tiedosto nimellä, vaikkakin tälläinen "yhteenotto" tapahtuu harvoin, esim. suurin osa yksikkötiedostoista jotka sisältää `@` merkin ovat tarkoitettu template yksiköksi. Jos template yksikköä kutsutaan ilman instanssi tunnistetta, kutsu yksinkertaisesti epäonnistuu, koska `%i` tarkennetta ei pystytä korvaamaan.
Vinkki:

- Suurin osa seuraavista komennoista toimii myös vaikka useampi yksikkö on annettu tarkennukseksi, kato systemctl(1) lisäinformaatiolle.
- `--now` kytkintä voidaan käyttää yhdessä `enable`, `disable`, ja `mask` kanssa vastaavasti käynnistää, lopettaa, tai naamioida yksikkö välittömästi kuin vastaisuudessa vasta uudelleen käynnistäessä.
- Paketti saattaa tarjota yksikköjä eri tarkoituksiin. Jos olet juuri asentanut paketin, `pacman -Qql paketti | grep -Fe .service -e .socket` voidaan käyttää tarkistamaan ja löytämään nämä yksiköt.

#### Statuksen tarkistaminen

Manuaali eri yksiköistä (mikäli yksikkö sitä tukee) voidaan näyttää komennolla:

    $ systemctl help yksikkö

Status yksiköstä, silloinkin jos se ei ole sillä hetkellä toiminnassa näytetään komennolla:

    $ systemctl status yksikkö

Tarkistaaksesi mikäli yksikkö on aktivoitu ja sen toiminta on sallittu:

    $ systemctl is-enabled yksikkö

#### Käynnistäminen, uudelleen käynnistys ja uudelleen lataaminen

Käynnistä yksikkö välittömästi:

    # systemctl start yksikkö

Lopeta yksikön toiminta välittömästi:

    # systemctl stop yksikkö

Käynnistä uudelleen yksikkö:

    # systemctl restart yksikkö

Uudelleen lataa yksikkö ja sen konfiguraatio:

    # systemctl reload yksikkö

Uudelleen lataa systemd managerin konfiguraatio, jolla skannataan uusia tai muutettuja yksikköjä:

    # systemctl daemon-reload

Huomautus: Tämä ei kysy muutettuja yksikköjä lataamaan uudelleen omaa konfiguraatiotaan. Katso uudelleen lataus esimerkki alhaalla.

#### Aktivointi

Aktivoi yksikkö käynnistymään heti bootatessa:

    # systemctl enable yksikkö

Aktivoi yksikkö käynnistymään heti bootatessa ja käynnistä se välittömästi:

    # systemctl enable --now yksikkö

Deaktivoi yksikkö käynnistymästä bootatessa:

    # systemctl disable yksikkö

#### Naamiointi

Naamioi yksikkö tehdäksesi käynnistämisestä mahdotonta (manuaalisesti sekä riippuvuutena, mikä tekeekin naamioinnista vaarallisen):

    # systemctl mask yksikkö

Paljasta yksikkö:

    # systemctl unmask yksikkö

### Virran hallinta

polkit on tarpeellinen virranhallinnalle epäoikeutettuna käyttäjänä. Jos olet lokaalissa systemd-logind käyttäjä sessiossa ja mikään muu sessio ei ole aktiivinen, seuraavat komennot toimivat ilman root-oikeuksia. Jos näin ei ole (esim. jos joku toinen käyttäjä on kirjautuneena tty:hyn), systemd kysyy automaattisesti root salasanaa.

Sammuttaminen ja uudelleen käynnistys järjestelmälle:

    $ systemctl reboot

Sammuta ja sammuta järjestelmästä virta:

    $ systemctl poweroff

Lakkauta järjestelmä:

    $ systemctl suspend

Laita järjestelmä taukotilaan:

    $ systemctl hibernate

Laita järjestelmä hybridiuni tilaan:

    $ systemctl hybrid-sleep

## Yksikkötiedostojen kirjoittaminen

Systemd:n syntaksi yksikkötiedostoissa (systemd.unit(5)) on saanut inspiraationsa XDG Desktop Entry Specification .desktop tiedostoista, joka taas on saanut inspiraationsa Microsoft Windows .ini tiedostoista. Yksikkötiedostot ladataan useista sijainneista (nähdäksesi täyden listan, suorita `systemctl show --property=UnitPath` terminaalissa), mutta tärkeimmät ovat (listattuna pienimmästä suurimpaan arvojärjestyksessä):

- `/usr/lib/systemd/system/`: yksiköt tarjoaa asennetut paketit
- `/etc/systemd/system/`: yksiköt jotka järjestelmän valvoja on asentanut

Huomautus:

- Latauspolut ovat täysin erilaiset kun suoritetaan systemd käyttäjä tilassa.
- systemd yksiköiden nimet voivat sisältää vain ASCII alfanumeerisia kirjaimia, alleviivauksia ja pisteitä. Kaikki muut kirjaimet täytyy korvata C-tyylisillä "\x2d" koodinvaihtomerkeillä tai antaa näiden ennaltamäärätyillä semantiikoilla ('@', '-'). Katso systemd.unit(5) ja systemd-escape(1) lisäinformaatiolle.

Kannattaa katsoa pakettien asentamia yksiköitä esimerkiksi. Lisää löytyy myös täältä systemd.service(5) § EXAMPLES.

Vinkki: Kommentit joiden alussa on `#` voidaan myös käyttää yksikkötiedostoissa, mutta vain uusilla riveillä. Rivin jälkeen annetut kommentit systemd parametreissä johtaa siihen ettei yksikkö aktivoidu.

### Riippuvuuksien käsittely

Systemd:llä riippuvuuksia pystytään ratkomaan suunnittelemalla yksikkötiedostot oikein. Kaikkein tyypillisin tapaus on, kun yksikkö A vaatii yksikköä B käynnistymään ennen yksikköä A. Siinä tapauksessa lisää `Requires=B` ja `After=B` `[Unit]` -osaan A:ta. Jos riippuvuus on vapaaehtoinen, lisää sen sijaan `Wants=B` ja `After=B`. Huomaa ettei `Wants=` ja `Requires=` vastaa `After=`, tarkoittaen siis sitä jos `After=` ei ole tarkennettu, nämä kaksi yksikköä käynnistetään rinnakkain.

Riippuvuuksia on yleensä asetettu palveluihin eikä kohteisiin. Esimerkiksi mikä tahansa palvelu joka konfiguroi verkkoyhteyden rajapinnan, nostaa `network.target` jonka takia omien yksiköiden suorittaminen sen jälkeen on riittoisa sillä `network.target` on käynnissä jo muutenkin.

### Palvelu tyypit

Käytettävissä on useita käynnistys tyyppejä, joista voi harkita itse sopivaa käynnistystapaa kirjottaessa omaa palvelu tiedostoa. Tämä asetetaan `Type=` parametrilla `[Service]` osassa:

- `Type=simple` (oletus): systemd käynnistää palvelun välittömästi. Tämä prosessi ei saa haarukoita muihin osasiin. Älä käytä tätä käynnistystapaa mikäli kyseinen palvelu vaatii muiden palveluiden kutsumista, ellei palvelu ole suoritinkannan aktivointi.
- `Type=forking`: systemd käynnistää palvelun kun prosessi haarukoituu muihin osasiin ja isäntä prosessi lopettaa toimintansa. Tyypillisille taustaprosesseille tämä on varmin vaihtoehto, ellet tiedä sen olevan tarpeeton. Kannattaa myös määrittää `PIDFile=`, jotta systemd voi seurata pääprosessia.
- `Type=oneshot`: tämä on hyödyllinen skripteille, jotka tekevät yhden asian ja lopettavat toimintansa. Voit myös haluta asettaa `RemainAfterExit=yes`, jotta systemd tulkitsee tämän palvelun aktiiviseksi vielä sen jälkeen kun prosessi on oikeasti lopettanut toimintansa.
- `Type=notify`: identtinen `Type=simple` kanssa, mutta vain siinä tapuksessa kun taustaprosessi lähettää signaalin systemd:lle ollessaan valmis. Viittauksen tähän toteutukseen tulee libsystemd-daemon.so:sta.
- `Type=dbus`: palvelu on valmis kun `BusName` ilmestyy DBus:sin järjestelmäväylässä.
- `Type=idle`: systemd viivästyttää palvelun binäärien suorittamista kunnes kaikki työt on saatu toimintaan. Muutoin tämä käynnistystapa vastaa `Type=simple`.

Katso systemd.service(5) § OPTIONS manuaali yksityiskoihtaisemmasta selityksestä liittyen `Type` arvoihin.

### Valmiiden yksiköiden muokkaaminen

Välttääksesi ristiriitoja pacman:in kanssa, pakettien mukana tulevia yksikkötiedostoja ei saisi suoraan muokata. On olemassa kaksi turvallista tapaa muokata yksikköä koskematta alkuperäiseen tiedostoon: luo uusi yksikkötiedosto, joka kirjoittaa edellisen yli tai luo drop-in pätkä, joka tulee alkuperäisen päälle. Molemmissa tapauksissa yksikkö täytyy ladata uudestaan saadaksesi muutokset käyttöön. Tämä voidaan tehdä joko muokkaamalla yksikköä `systemctl edit` (joka lataa yksikön uudestaan automaattisesti) tai lataamalla kaikki yksiköt uudestaan komennolla:

    # systemctl daemon-reload

Vinkki:

- Voit käyttää systemd-delta nähdäksesi minkä yksikkötiedostojen yli on kirjoitettu tai laajennettu ja tarkalleen mitä muutoksia on tehty.
- Käytä `systemctl cat yksikkö` nähdäksesi yksikön sisällön ja kaikki siihen liittyvät drop-in pätkät.

#### Korvaavat yksikkötiedostot

Korvataksesi yksikkötiedoston `/usr/lib/systemd/system/yksikkö`, luo tiedosto `/etc/systemd/system/yksikkö` ja uudelleen aktivoi yksikkö päivittämään symlinkit:

    # systemctl reenable yksikkö

Vaihtoehtoisesti, suorita:

    # systemctl edit --full yksikkö

Tämä avaa `/etc/systemd/system/yksikkö` muokkaus ohjelmassa (kopioimalla asennetun version jos se ei ole olemassa) ja automaattisesti lataa sen kun olet valmis muokkauksen kanssa.

Huomautus: Korvaavat yksiköt pysyvät käytössä, vaikka Pacman päivittää alkuperäiset yksiköt tulevaisuudessa. Tämä tekee järjestelmän ylläpidosta hankalaa ja siksi seuraava lähestymistapa on suotavampaa.

#### Drop-in tiedostot

Luodaksesi drop-in tiedostoja yksikkötiedostoille `/usr/lib/systemd/system/yksikkö`, luo polku `/etc/systemd/system/yksikkö.d/` ja aseta .conf tiedostot sinne kirjoittaaksesi tiedostojen yli tai lisätäksesi lisää vaihtoehtoja. systemd jäsentää sekä asettaa nämä tiedostot alkuperäisen yksikön päälle.

Helpoin tapa on suorittaa komento:

    # systemctl edit yksikkö

Tämä avaa tiedoston `/etc/systemd/system/yksikkö.d/override.conf` tekstin käsittely ohjelmassa (luoden sen jos tarpeellista) ja automaattisesti lataa yksikön kun olet muokannut tiedoston.

Huomautus: Kaikkia avaimia ei pysty ylittämään drop-in tiedostoilla. Esim. vaihtaaksesi `Conflicts=` korvaava tiedosto on tarpeellinen.

#### Palauta toimittajan versioon

Palauttaaksesi tehdyistä muutoksista joihin on käytetty `systemctl edit` käytä komentoa:

    # systemctl revert yksikkö

#### Esimerkkejä

Jos haluat yksinkertaisesti lisätä vaihtoehtoisen riippuvuuden yksikölle, voit mahdollisesti luoda seuraavan mukaisen tiedoston:

    /etc/systemd/system/yksikkö.d/customdependency.conf

    [Unit]
    Requires=uusi riippuvuus
    After=uusi riippuvuus

Vaihtaaksesi `ExecStart` direktiivin yksikölle, joka ei ole tyyppiä `oneshot`, luo seuraavan mukainen tiedosto:

    /etc/systemd/system/yksikkö.d/customexec.conf

    [Service]
    ExecStart=
    ExecStart=uusi komento

Huomaa kuinka `ExecStart` pitää tyhjentää ennenkuin se voidaan uudelleenasettaa [1]. Sama pätee jokaiselle komponentille, joka pitää määrittää useaan kertaan esim. `OnCalendar` ajastimille.

Vielä yksi esimerkki palvelun automaattisesta uudelleen käynnistämisestä:

    /etc/systemd/system/yksikkö.d/restart.conf

    [Service]
    Restart=always
    RestartSec=30

## Kohteet

systemd käyttää kohteita (englannin target) yksiköiden kokoamiseen yhdeksi ryhmäksi riippuvuuksien välityksellä ja yhdenmukaistettuina synkronointi kohtina. Ne hoitavat samoja asioita kuin ajotasot, mutta käyttäytyvät erilailla.

### Hae nykyiset kohteet

Seuraavaa tulisi käyttää systemdn alla, sen sijaan kuin ajotasona `runlevel`:

    $ systemctl list-units --type=target

### Kartoittaminen SysV ajotason ja systemd kohteiden välillä

SysV Ajotaso | systemd Kohde | Huomiot
--- | --- | ---
0 | runlevel0.target, poweroff.target | Pysäytä järjestelmä.
1, s, single | runlevel1.target, rescue.target | Yhden käyttäjän tila.
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Käyttäjän määrittelemät/Sivu kohtaiset ajotasot. Oletukselta identtinen 3 kanssa.
3 | runlevel3.target, multi-user.target | Monikäyttäjä, ei-graafinen. Käyttäjät voivat yleensä kirjautua sisään useammasta konsolista tai verkon kautta.
5 | runlevel5.target, graphical.target | Monikäyttäjä, graafinen. Sisältää yleensä kaikki palvelut ajotaso 3:sta sekä graafisen sisään kirjautumisen.
6 | runlevel6.target, reboot.target | Uudelleen käynnistys
emergency | emergency.target | Hätätila komentotulkki

### Vaihda nykyinen kohde

systemd:ssä tavoitteet voidaan paljastaa target yksiköiden avulla. Niitä voidaan muuttaa seuraavasti:

    # systemctl isolate graphical.target

Tämä muuttaa vain sen hetkisen tavoitteen, ja sillä ei ole vaikutusta seuraavassa käynnistyksessä. Tämä on yhtäläinen komentojen `telinit 3` tai `telinit 5` kanssa Sysvinit:issä.

### Vaihda oletus kohde johon käynnistetään

Oletus tavoite on `default.target`, joka on symlinkki tavoitteelle `graphical.target`. Tämä suunnilleen vastaa vanhaa ajotasoa 5.

Varmistaaksesi vanhan tavoitteen systemctl avulla:

    $ systemctl get-default

Vaihtaaksesi oletus tavoitteen mihin käynnistetään, vaihda `default.target` symlinkkiä. systemctl avulla:

    # systemctl set-default multi-user.target

    Removed /etc/systemd/system/default.target.
    Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Vaihtoehtoisesti, lisää yksi seuraavista kernelin parametreista käynnistyslataimeen:

- `systemd.unit=multi-user.target` (joka vastaa karkeasti vanhaa ajotasoa 3),
- `systemd.unit=rescue.target` (joka vastaa karkeasti vanhaa ajotasoa 1).

## systemd komponentit

Joitain (ei kokonaisuudessa) systemd:n komponentteja ovat:

- systemd-boot — yksinkertainen UEFI boot manager;
- systemd-firstboot — perus järjestelmän asetusten alustaminen ennen ensimmäistä käynnistystä;
- systemd-homed — siirrettävät ihmiskäyttäjän tilit;
- systemd-logind — istunnon hallinta;
- systemd-networkd — verkon konfiguroinnin hallinta;
- systemd-nspawn — kevyt nimiavaruuden säilö;
- systemd-resolved — verkon nimi resoluutio;
- systemd-sysusers(8) — luo järjestelmäkäyttäjiä ja ryhmiä ja lisää käyttäjiä ryhmiin asennuksen yhdteydessä tai käynnistyksen aikana;
- systemd-timesyncd — järjestelmän ajan synkronointi läpi koko verkon;
- systemd/Journal — järjestelmän kirjaukset;
- systemd/Timers — monotoniset tai reaaliaikaiset ajastimet `.service` tiedostojen hallintaan tai tapahtumille, kohtuullinen vaihtoehto cron:ille.

## Vinkkejä ja konsteja

## Vianmääritys

### Epäonnistuneiden palveluiden tutkiminen

systemd palvelut, jotka eivät onnistuneet käynnistymään, löytyvät:

    $ systemctl --state=failed

Tutki näiden kirjauksia, löytääksesi syyn sille. Katso systemd/Journal#Filtering output lisätiedolle.

### Bootaus ongelmien tutkiminen

systemd sisältää monia vaihtoehtoja ongelmien tutkimiseen boot prosessissa. Katso boot debugging lisäohjeille ja asetuksille Boot viestin tallentamiseksi ennenkuin systemd aloittaa toimintansa boot prosessista. Katso myös systemd debuggaus dokumentaatio.

### Palvelun tutkiminen

Jos jotkin systemd palvelut eivät toimi oikein tai haluat enemmän tietoa siitä mitä tapahtuu, aseta `SYSTEMD_LOG_LEVEL` alusta muuttuja tähän: `debug`. Esimerkiksi, systemd-networkd taustaprosessin suoritukseen debug tilassa:

Lisää Drop-in tiedosto palvelulle lisäämällä kaksi riviä:

    [Service]
    Environment=SYSTEMD_LOG_LEVEL=debug

Tai vastaavasti aseta alusta muuttuja manuaalisesti:

    # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

sitten käynnistä uudelleen systemd-networkd ja katso lokikirjaa palvelulle jossa on `-f`/`--follow` asetus.

### Sammutus/uudelleen käynnistys vie älyttömästi aikaa

Jos sammuttus prosessi vie paljon aikaa (tai vaikuttaa jäätyvän) todennäköisesti jokin palvelu jota ei ole olemassa on syynä. systemd odottaa jonkin aikaa jokaista palvelua lopettamaan ennenkuin systemd katkaisee sen toiminnan. Jos haluat tietää onko oma järjestelmäsi tämän vaikutuksen alaisena, katso tämä artikkeli.

## Katso myös

- Wikipedia:systemd
- Virallinen nettisivu
  - systemd optimointi
  - systemd FAQ
  - systemd Vinkkejä ja konsteja
- systemd(1)
- Muut jakelut
  - Gentoo:Systemd
  - Fedora:Systemd
  - Fedora:How to debug Systemd problems
  - Fedora:SysVinit to Systemd Cheatsheet
  - Debian:systemd
- Lennartin blogi tarina, päivitys 1, päivitys 2, päivitys 3, yhteenveto
- Debuggaa Systemd Palveluita
- systemd järjestelmän hallinnoinnille (PDF)
- Kuinka Käyttää Systemctl:ää Systemd Palveluiden ja Yksiköiden Hallintaan
- Tilan hallinta systemd-logind avulla
- Emacs Syntaksin maalaaminen Systemd tiedostoille
- Kaksi osainen selvitys artikkeliin The H Open lehdessä.

Category:

- Init (Suomi)