Tänased teemad init runlevelid systemd pisike harjutus
Init – Kõige Tähtsam Deemon
• Init on süsteemis Esimene Deemon
• Initi ülesandeks on tegeleda kõigi teiste süsteemi tööks vajalike protsessidega
Init – Kõige Deemonite Ema
● Init on esimene protsess mis alglaadimisel käivitatakse
● init on „daemon“ ehk taustaprotsess mis töötab kogu süsteemi töötamise ajal
● Kõik teised protsessid on initi „järglased“ -- init käivitab kõik teised protsessid (daemonid) otseselt või kaudselt
● init „lapsendab“ kõik „orvuks jäänud“ (hüljatud) protsessid
● Alglaadimisel käivitab kernel initi (selle programmi nimi on kerneli koodi jõuga sisse kirjutatud) ja satub paanikasse (kernel panic) kui vastav rakendus puudub.
● tüüpiliselt on init PID (process ID 1)
Init – ajalooga tegelane
● Initi juured on sügaval klassikalises UNIXis
● Ilmus juba UNIX System III (75) ja System V (83)
● Klassikalist initit on kahes „maitsevariandis“ „BSD- stiilis“ (linuxitest kasutas Slackware) ja „SystemV-stiilis“ -- seda kasutas kuni viimase ajani enamik linuxeid
● Kuigi moodsad distributiivid on kõik enamasti migreerinud juba systemd peale ei lähe „SysV-init“ „stiilis“ asjad esialgu veel mitte kusagile
● Tagasiühilduvuse huvides sälitatakse vajalikke init osi
Kuidas init oma tööd teeb
● runlevel – runlevel on eeldefineeritud süsteemi „olek“ – tüüpilises linuxi süsteemis on 7 runlevelit (0-6) – linuxi standardsed runlevelid:
● 0 Halt – süsteemi töö peatamine ● 1 Single-user – ühekasutajarežiim süsteemi haldamiseks ja konfigureerimiseks ● 2 – multiuser, ilma võrguteenusteta ● 3 – multiuser + networking – serveri kontekstis süsteemi normaalne töörežiim ● 4 – defineerimata, ise seadistatav – vaikimisi pole kasutusel võimalik defineerida oma olek ● 5 – runlevel 3 + GUI – graafiline kesskkonna tavaline töörežiim ● 6 -- „kuum“ restart – süsteemi taaskäivitamine „reboot“
Kuidas init oma tööd teeb
● init scripts – tavaline shelli script (sh või bash enamasti sh) – peab vastama teatud nõuetele
● käsurea parameetrid start | stop | reload | restart | force-reload | status ● peab suutma tagastada viisaka väljundkoodi (exit code) ● päises sisaldab infot sõltuvuste kohta (paha-paha!) – init scripte saab ka ise luua võttes aluseks mõne olemasoleva või kasutades linuxi dokumentatsiooniga kaasas olevat malli (linuxi keeles skeleton)
Paneme 2 ja 2 kokku
● igal protsessil peab olema oma käivitusskript /etc/init.d kataloogis
● igale runlevelile vastab /etc/rc.dX kataloog
● iga kataloog sisaldab symlinke vastava runleveli jaoks käivitatavatele või seisatavatel init scriptidele
● rc.local on spetsiaalne skript roodu tarbeks
● rcS.d :(
rc.dX süntaks
● symlinkid /etc/init.d/ skriptidele
● prefiks S tähendab protsessi käivitamist
● prefiks K tähendab protsessi seiskamist
● Number näitab prioriteeti – väiksema numbriga skript käivitatakse varem
SysV-initi puudused
● Kuigi init on vana, hea ja ajahambale hästi vastu pidanud süsteem, on tal mõningaid puudusi – suhteliselt keerukas ja ebaintuitiivne on teenuste käivitamine „nõudmise“ peale – init skriptid ei ole eriti kasutajasõbralikud modifitseerimise ja haldamise suhtes – tihtipeale sõltub süsteemi haldur rakenduse looja loodud init-scriptist, mis on sõna otses mõttes KEHVASTI programeeritud – puudulik automaatne protsessihaldus – näiteks puudub mehhanism vajalike protsesside automaatseks taaskäivitamiseks, kui nad on nii-öelda „pange pannud“ – puudulik integratsioon udev seadmehalduriga. Puudub võimalus initit seadistada nii, et seadme ühendamisel käivitatakse automaatselt mõni vajalik daemon – ebamugav sõltuvuste haldus, iga protsess peab ise teadma oma sõltuvusi ja need on kirjeldatud protsessi init scriptis
Alternatiivid SysV-initile
● Eelmisel slaidil toodud puudustest üle saamiseks on loodud mitmeid alternatiive – Upstart – loodi sysVinit asenduseks, aga suhteliselt ebaõnnestunud arhitektuur nullib head omadused ära. Kust leiame: Chrome OS – OpenRC – pole päris init vaid sõltuvuse-teadlik teenusehaldur, võimalik kasutada SysV-init täiendusena – launchd ja SystemStarter – OSX – systemd – see tegelane, kes erinevate „initite“ „sõjas“ tundub olevat võitjaks jäänud, enamik moodsaid linuxi distributiive on otsustanud systemd kasuks
Systemd
● Systemd on Linux'i süsteemi ja teenuste haldur.
● Nagu init on ka tema Kõigi Deemonite Ema
● Kirjutatud C keeles, võimaldamaks suuremat töökiirust võrreldes eellastega, kuid sellest hoolimata on tagasiühilduv SystemV ja LSB käivitusskriptidega.
● Praktikas näeme, et enamik distributiive on mingid „hübriidid“, kus mingit osa süsteemseid protsesse hallatakse systemd abil ja tagasiühilduvuse huvides vahib meile vana hea SysV-init ka otsa
Systemd
● Põhilised omadused – Agressiivne teenuste käivitamise paralleliseerimine – Sõltuvustepõhine teenuste käivitamine – Soklitel ja D-Bus'il põhinevalt vajadusepõhine teenuste käivitamine – Protsesside haldamine cgroup'ide abil – Kettajagude külgehaakimise vajadusepõhine haldamine – Protsessihaldus ja jälgimine (võimeline „pange pannud“ protsesse taaskäivitama)
Systemd
● Arhitektuur – systemd on tarkvarapakett, mis koosneb
● mitmest protsessist (dameon) ● jagatud teekidest (libraries) ● käsureautiliitidest (administraatorile) ● arendaja utiliitidest (arendajatele) – tähtsamad komponendid
● systemd ● logind ● journald ● networkd ● user session ● D-Bus daemon – oluline nüanss – oskab töötada koos udeviga
Kuidas systemd töötab
● Unit file – systemd alternatiiv init scriptile – realiseeritud deklaratiivses süntaksis (vs. imperatiivne nagu initis) – palju kergemini loetavam ja hallatavam – unit file ei piirdu ainult protsessi käivitusfaili rolliga vaid võib olla ka mõnda teist tüüpi, näiteks
● monteerimispunkt ● virtuaalse seadmefaili loomiseks ● sokli (socket) loomiseks
Kuidas systemd töötab
● Näide systemd „unit“ failidest
● suffiksi järgi tehakse kindlaks uniti tüüp
● /etc/systemd/ administraatori mängumaa
● /usr/lib/systemd süsteemsed failid
● target „runleveli“ analoog
● wants sõltuvuste käitlemine
Why systemd sucks?
● Breaking promises and immaturity – udevi allakugistamine (enam ei saa udevi eraldi kasutada) ● Stability Promises (and problems) – lots of bugs, instability, security holes ● Scope creep (bloat) – assimilates udev, mount, IP forwarding etc. – unneccessary and duplicating components: logging, web server(!) etc.
Systemd vastuolud
● Bloatware?
● Ajab oma kombitsad sinna kuhu ei peaks?
● But devs like it!
● There is no escape!
● We still have hope!
Abiks linke ja harjutus
● https://wiki.archlinux.org/index.php/Systemd#Ta rgets
● https://www.digitalocean.com/community/tutoria ls/understanding-systemd-units-and-unit-files
● https://wiki.archlinux.org/index.php/Init
● https://wiki.archlinux.org/index.php/Initscripts/ru nlevels
● https://fedoraproject.org/wiki/SysVinit_to_Syste md_Cheatsheet
● http://suckless.org/sucks/systemd