A runit működése

A lap 2006. október 16., 01:48-kori változata

A daemontools szabad reimplementációja; majdnem minden, ami igaz a runitre, igaz a daemontoolsra is, és fordítva. Az ötlet az, hogy juttassuk érvényre a Unix-filozófiát: egy program egy dolgot csináljon, lehetőleg jól és hatékonyan, de legyen képes más programokkal együttműködni. A runit csomag egy-egy programja tipikusan kevesebb, mint ezer sor C-kódból áll, és sosem nő a memóriafoglalása. Ha a runitot statikusan linkeljük a dietlibc-hez, akkor az 1-es processzként futó program csak kb. 20KB-ot vesz igénybe. A BSD-licenchez hasonló licenc alatt érhető el.

Az initet és az initscripteket váltja ki, valamint segít a naplózás megszervezésében. Be lehet vezetni kicsit, nagyon, és teljesen.

Ha kicsit vezetjük be, akkor megmarad a System V init, de mellette kapunk:

• Szolgáltatásmenedzsmentet. A szolgáltatások
  • tiszta környezettel indulnak
  • újraindulnak, ha kilépnek
  • opcionálisan megbízható naplózást kapnak
    • naplóüzenet nem vész el naplózás közben
    • méret alapján rotált logok
    • utófeldolgozás lehetősége
    • akkor is működik, ha a szolgáltatás chrootban fut
    • a logolás és a szolgáltatás egymástól függetlenül újraindítható/leállítható
  • kiválasztott felhasználók sudo nélkül is menedzselhetik őket
  • könnyedén lekérdezhető a státuszuk
  • könnyedén küldhető nekik signal
  • könnyedén biztosíthatjuk ezeket a tulajdonságokat a felhasználók saját "szolgáltatásainak" - pl.:
    • screen, benne irssi
    • eggdrop bot (sajnos át kell írni, mert mindenképpen a háttérbe akarja rakni magát)
    • fetchmail
    • signify
    • akár apache vagy egyéb

Ha nagyon bevezetjük, akkor emellett még az initet is kiváltjuk, de a rendszerindulást továbbra is a hagyományos initscriptjeink vezénylik le, csak az inittab válik feleslegessé. Emellett gyorsabbá válik az indítás és a leállítás, mert sokmindent egyszerre fog csinálni a runit (azért nem kell azzal foglalkoznia, hogy minek mi után kell jönnie, mert ezt az intelligenciát nekünk kell megavlósítanunk a run scriptekben - l. később).

Ha teljesen bevezetjük, akkor az rcS után már csak a runit által menedzselt szolgáltatásaink futnak, vagyis az "rc 2" már nem kell, hogy lefusson.

1 Architektúra

• Minden szolgáltatáshoz tartozik egy könyvtár (directory), amiben:
  • Megvan az a program (általában script), ami az adott szolgáltatást elindítja és futtatja (és run névre hallgat); addig nem léphet ki, amíg a szolgáltatás nem lépett ki
  • A runit létrehoz egy supervise könyvtárat - l. később
  • Lehet egy down nevű file, ami azt jelzi, hogy a szolgáltatás normális állapota az, hogy nem fut
  • Lehet egy log nevű könyvtár, ha a szolgáltatáshoz naplózást is szeretnénk - l. később
  • Lehet egy check nevű program, ami 0-ás visszatérési értékkel lép ki, ha a szolgáltatás működik (ami nem azonos azzal, hogy fut), egyébként nullától különbözővel
  • Lehet egy finish nevű program, amit abban az esetben kell lefuttatni, ha a run kilép

Ezeket az ún. service directorykat általában a /service alá symlinkeljük be, ha az adott szolgáltatást futtatni akarjuk.

A /service könyvtárat figyeli a runsvdir, és minden alkönyvtárra indít egy runsv folyamatot. Erről rövidsen lesz szó.

2 Telepítés

• Ajánlott verzió: legalább 1.6 (bár a korábbiak is használhatók)
• Debianhoz és Ubuntuhoz van szép runit csomag, ez csak felrakja a runitot, de nem cseréli le az initet - mindenféle körültekintés nélkül telepíthetjük
  • Van runit-run csomag is, ami le is cseréli az initet - csak óvatosan: reboot után, ha nem vigyázunk, csak a konzolról fogunk tudni belépni, mert nem indul el az sshd
• Nyilván fel lehet rakni forrásból is
  • Alapból a djb-féle /package, /command könyvtárstruktúrát használja, aminek ugyan van előnye, de azért eléggé eltér az LFS-től

3 Rendszerindítás runittal

Ha init helyett a runit indul, akkor a /etc/runit/1 nevű scriptet indítja el először. Ennek a tartalma lehet pl ez (a runit-run csomagban is ilyesmi van):

#!/bin/sh
# system one time tasks

PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/X11
export PATH

/etc/init.d/rcS
/etc/init.d/makedev start
/etc/init.d/systune start
/etc/init.d/ud start
/etc/firewall/firewall start
/etc/init.d/rmnologin start
/etc/init.d/xend start
/etc/init.d/xendomains start

touch /etc/runit/stopit
chmod 0 /etc/runit/stopit

Ne feledjük, hogy a beállított és exportált környezeti változókat a script gyermekfolyamatai örökölni fogják.

Az 1-es script tartalmazza a rendszerindításkor kiadandó parancsok listáját, emiatt nem hordozható korlátozás nélkül. Vegyük észre, hogy a fenti scriptben használhattunk volna rc.d mechanizmust is a szolgáltatások elindítására, ami

• kicsit nehezebben átlátható,
• egy picit lassúbb, cserébe
• modulárisabb és
• könnyebb automatizálni a karbantartását.

A /etc/runit/1 után a /etc/runit/2 jön (micsoda meglepetés):

#!/bin/sh

PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin

exec env - PATH=$PATH \
runsvdir -P /var/service 'log: ...........................................................................................................................................................................................................................................................................................................................................................................................................'

Innentől, amig a runsvdir ki nem lép, monitorozza a szolgáltatásainkat és fut a rendszer.

Láthatjuk, hogy a 2-es script lényegében semmilyen rendszerspecifikus dolgot nem tartalmaz, hordozható.

Ha kilép a runsvdir, kilép a /etc/runit/2 is; ha a visszatérési értéke 0 volt, elindul a /etc/runit/3, ami a leállításért felelős.

Ha nem 0 volt a 2-es script visszatérési értéke, akkor a runit újra elindítja.

A 3-as script tartalma például a következő lehet:

#!/bin/sh
exec 2>&1

PATH=/sbin:/bin:/usr/sbin:/usr/bin

LAST=0
test -x /etc/runit/reboot && LAST=6

echo 'Waiting for services to stop...'
sv -w196 force-stop /var/service/*
sv exit /var/service/*

echo 'Shutdown...'
/etc/init.d/rc $LAST

Elvileg a 3-as script is lehetne rendszerfüggő, mivel a rendszer leállításával kapcsolatos parancsokat kell benne felsorolnunk, azonban gyakran nem az.

Ha létezik és végrehajtható a /etc/runit/stopit file, akkor a runit a CONT signal hatására leállítja a rendszert. A ctrl-alt-del-t kezelő scriptből adhatunk rá futtatási jogot, ha azt akarjuk, hogy a ctrl-alt-del hatása leállítás legyen.

4 Ajánlott irodalom

• runit - a UNIX init scheme with service supervision - a runit honlapja