Upstart

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(Az upstart felépítése)
(Miért érdemes váltani?)
65. sor: 65. sor:
 
*Energiafelhasználás csökkentése miatt a meghajtó nem biztos, hogy felpörög míg a busz vizsgálat folyik, így akár hosszabb ideig sem jelenik meg
 
*Energiafelhasználás csökkentése miatt a meghajtó nem biztos, hogy felpörög míg a busz vizsgálat folyik, így akár hosszabb ideig sem jelenik meg
 
*Hálózati eszközöket bármikor hozzáadhatunk, eltávolíthatunk.
 
*Hálózati eszközöket bármikor hozzáadhatunk, eltávolíthatunk.
*A firmware-t az eszköz detektálása után kell betölteni, ezután válik az eszköz használhatóvá a rendszer számára .
+
*A firmware-t az eszköz detektálása után kell betölteni, ezután válik az használhatóvá a rendszer számára .
 
*Egy partíció montolása a <tt>/etc/fstab</tt>-ban igényelhet különböző eszközöket a <tt>/usr</tt>-ből. Amennyiben a <tt>/usr</tt> hálózati fájlrendszer, úgy addig nem lehet végrehajtani a mountot, amíg a hálózat nem működik.
 
*Egy partíció montolása a <tt>/etc/fstab</tt>-ban igényelhet különböző eszközöket a <tt>/usr</tt>-ből. Amennyiben a <tt>/usr</tt> hálózati fájlrendszer, úgy addig nem lehet végrehajtani a mountot, amíg a hálózat nem működik.
   

A lap 2011. január 12., 13:14-kori változata

Az upstart a hagyományos SysV initet váltja ki egy eseményvezérelt megoldással. Kezeli a taskok és szolgáltatások bootolás alatti indítását, rendszerleállás alatti leállítását, és felügyeli őket a rendszer működése során.

Tartalomjegyzék

1 Bevezető

A hagyományos SysV init a rendszerindítás során elvégzendő feladatokat fix sorrendben, minden párhuzamosság nélkül hajtja végre. Konfigurációjában mereven rögzíteni kell, hogy egy-egy állapotban (runlevelben) -- ill. az oda való váltás során -- milyen programokat kell futtatni/elindítani.

A rugalmasság hiánya miatt, az init képtelen elegánsan kezelni egy modern pc-n előforduló taszkok nagy részét. Pl.:

  • Gép futása közben USB pen drive-ok és különféle hordozható tárolók illetve hálózati eszközök hozzáadása vagy eltávolítása nehézkes.
  • Új tárolóeszközök felismerése, és csatlakoztatása során a rendszer megakadhat.
  • Az eszköz firmware-jének betöltése sem elegáns, ami detektálás után, de használhatóság előtt szükséges.

Az upstart eseményvezérelt modellje lehetővé teszi, hogy az eseményekre (eventek-re) a keletkezésükkor reagáljon.

2 Design

Az upstart aszinkron módon működik, kezeli a szolgáltatások taszkjainak indítását a boot alatt, leállítását a leállás során, felügyeli azokat a rendszer futása közben.

Alapvetően tervezési cél volt a sysvinit-tel való visszafelé kompatibilitás, illetve könnyű átállási lehetőség. Az upstart képes futtatni a módosítás nélkül a sysvinit scripteket, ami miatt nagyban különbözik a többi init helyettestől. Az init helyettesítők általában teljes átállást igényelnek, és nem támogatják a hagyományos, és az új indítási metódusok kevert használatát.

3 Alkalmazás

Az upstart-ot elsőként az ubuntu 6.10-ben alkalmazták 2006 végén a sysvinit helyettesítésére. Habár az upstart daemont használták, a legtöbb szolgáltatás még mindig a régi sysvinit scriptet használta. (Jelenleg is sok program még a hagyományos init scrioptet használja. Pl.: apache2) Ennek az volt az oka, hogy bizonyos feature-ök még hiányoztak, így a meglévő scripteket nem lehetett helyettesíteni a natív upstart szolgáltatás leírókkal. Az ubuntu 9.10-ben használták először a teljesen natív upstart bootfolyamatot. Ahogy az upstart kiforrottabbá válik, a szerepkörét ki akarják terjeszteni azokra a feladatokra, melyeket a cron, anacron, és az atd kezel.

Az upstart felváltotta a sysvinit-et a fedora 9-ben is, az átállás hasonló módon történt, mint az ubuntu esetén, azaz először a sysvinit-et helyettesítették, és meghagyták a meglévő scripteket, bár a fedora 15-ös kiadásban az upstart-ot a systemd-vel akarják helyettesíteni. A Redhat is tartalmazza az upstart-ot a Redhat Enterprise Linux 6 kiadásában.

  • A Debiannál a váltást a Squeeze kiadásban tervezik. (A testing változatban már telepíthető)
  • Az openSuse-ban a 11.3 Milestone 4 verzió óta megtalálható az upstart, de nem alapértelmezett.
  • A Nokia Internet tablet-ek Mameo 5-ös operációs rendszerében a sysvinit-et az upstart helyettesíti.
  • Upstart-ot használnak a Palm webOS-ében, melyet a Palm Pre okos telefonokra szántak.
  • Upstart-ot használnak a Google Chrome OS-ben is.

4 Kiemelt feature-ök

  • A taskok és szolgáltatások események által indulnak el vagy állítódnak le.
  • Az események, a taszkok és szolgáltatások indulásakor vagy leállásakor generálódnak.
  • Eseményeket a rendszer összes többi folyamatától lehet fogadni.
  • Szolgáltatások újjászülethetnek, ha meghalnak váratlanul.
  • Szülő folyamattól független a daemonok felügyelete, illetve azok újjászületésének kezelése.
  • D-bus-on történő kommunikáció az init daemonnal.

5 Tervezett feature-ök

  • Az események időzített intervallumban, vagy ütemezett időpontokban generálódnak.
  • Események generálódnak, amint fájlok vagy könyvtárok megváltoznak.
  • Felhasználói szolgáltatások, melyeket a userek saját maguk indíthatnak el vagy állíthatnak le.

6 Miért érdemes váltani?

Meghatározott mennyiségű script egymás után történő végrehajtása jól működött egészen mostanáig. Ahogy a Linux egyre inkább kezdett a modern számítástechnika felé haladni, úgy okozott a System V init nehézségeket. A régi megközelítés egészen jól működik, amíg garantálni tudjuk, hogy a boot folyamat során a dolgok rendelkezésünkre állnak. Így el lehet helyezni egy folyamat init scriptjét azután a pont után, aminél tudjuk, hogy az eszköz működni fog.

Tipikus sorrendi megkötések például:

  • A mountolás előtt a merevlemezt/merevlemezeket felfedezzük, inicializáljuk, detektáljuk a rajta lévő partíciókat.
  • A hálózati eszközöket először felfedezzük, inicializáljuk, és utána építjük fel a hálózatot.

Ezek tíz évvel ezelőtt működtek, akkor most miért nem jók? Az egyszerű válasz az, hogy a számítógép és kezelése sokkal rugalmasabbá vált.

  • Meghajtókat csatlakoztathatunk és választhatunk le bármikor. Pl.: USB meghajtók
  • Tároló buszok előre meg nem határozott számú meghajtót engedélyeznek, így azokat folyamatosan vizsgálni kell, a gyakori vizsgálat pedig nem blokkolhatja a rendszert.
  • Energiafelhasználás csökkentése miatt a meghajtó nem biztos, hogy felpörög míg a busz vizsgálat folyik, így akár hosszabb ideig sem jelenik meg
  • Hálózati eszközöket bármikor hozzáadhatunk, eltávolíthatunk.
  • A firmware-t az eszköz detektálása után kell betölteni, ezután válik az használhatóvá a rendszer számára .
  • Egy partíció montolása a /etc/fstab-ban igényelhet különböző eszközöket a /usr-ből. Amennyiben a /usr hálózati fájlrendszer, úgy addig nem lehet végrehajtani a mountot, amíg a hálózat nem működik.

A fent felsorolt funkciók megvalósításához eddig a jelenlegi rendszert meg kellett hackelni, melynek eredménye egy bugokkal teli tűzdelt rendszer lett. Ezért szükségessé vált egy új rendszer, mely ezeket a dolgokat probléma nélkül megoldja.

Egy olyan init rendszerre volt szükség, mely dinamikusan tudja rendezni az indítási sorrendet a hardverek és azok felismerési sorrendje alapján. Erre problémára nyújt megoldást az upstart.

7 Az upstart felépítése

Az upstart eseményeken alapszik, melyek a következőket tartalmazhatják:

  • A rendszer elindult.
  • A root fájrendszer írható.
  • Egy blokk eszköz lett hozzáadva a rendszerhez.
  • A fájrendszer fel lett mountolva.
  • Egy adott időpontban vagy ismétlődő időszakban.
  • Egy másik job elkezdte futását, vagy befejeződött.
  • A fájlt a meghajtón módosították.
  • Fájlok találhatóak sorban állási könyvtárban.
  • Hálózati eszköz detektálva.
  • Alapértelmezett route lett hozzáadva vagy eltávolítva.

Valójában a rendszer bármely folyamata küldhet eseményeket az init daemonnak a vezérlő socketjükön keresztül, tehát nincs korlátozás.

Minden folyamatnak van egy életciklusa, mely a következőképpen alakul: A futás (running) és a várakozás (waiting) a két pihenő állapot, alapértelmezetten azt várjuk, hogy egy folyamat ezen állapot valamelyikében maradjon addig, amíg egy új esemény be nem következik.

Az indítás (starting), leállítás (stopping), újjászületés (respawning) állapot ideiglenes. Ezekben engedjük meg a folyamatoknak, hogy shell scriptet futtassanak az indítás előkészítésére, vagy a leállítás utáni tisztítás végrehajtására. Azok a folyamatok melyek terminálódnak, mielőtt egy esemény leállítaná őket, az újjászületésük előtt futtathatnak scripteket.

A kommunikáció az init daemon és a többi folyamat között kétirányú, a jobok állapota lehet kérés a többi folyamat felé.

8 Kompatibilitás

Számtalan rendszer adminisztrátor van aki megtanulta, hogyan működik a Linux, nem szeretne azonnal mást megtanulni, illetve számtalan könyv van, mely a meglévő szoftverekről ad leírást, így az upstart-ot még néhány évig nem fogják tartalmazni. Emiatt nagyon fontos a kompatibilitás. Ezen okból az upstart a jövőben is futtatni fogja a meglévő szkripteket, hogy a csomagokat ne kelljen frissíteni addig, amíg a szerzőjük nem szeretné.

9 Az upstart scriptjeinek felépítése

Az upstart jobjainak a fájl formátuma még nem kiforrott jelenleg, így ha később frissíteni szeretnénk az upstart-ot, a meglévő fájlokat is javítani kell majd. A jobok a /etc/init könyvtárban találhatóak, ahol a fájlok nevei utalnak a jobok nevére természetesen a .conf kiterjesztés nélkül. Ezek egyszerű szövegfájlok, melyek nem futtathatóak. A formátum egy vagy több TAB-ot spacet whitespace karakterként kezel, hacsak nem aposztrófok vagy idézőjelek között találhatóak. Idézőjelek között megengedett a sortörés. A kommentek #-el kezdődnek, és sor végéig tartanak.

9.1 Jobok írása


9.1.1 Exec és script

Az összes job fájlnak tartalmaznia kell egy exec vagy script strófát(stanza). Ez határozza meg, hogy mit kell futtatnia a job-nak.

Az exec elérési útvonalat és opcionális paramétereket biztosít egy binárishoz a fájlrendszeren.

exec /bin/foo –opt –xyz foo bar

A script-ben egy shell kódot adhatunk meg, mely a /bin/sh által fog lefutni. Ha a –e shell opciót alkalmazzuk, akkor bármely parancs hibája esetén a script végrehajtása megszakad. A strófát az end script sorral zárjuk.

script
    # do some stuff
    if [...];  then
        ...
    fi
end script

9.1.2 Pre-start script és post-stop script

További shell kódot lehet futtatni egy bináris vagy script előtt vagy után melyeket exec-el vagy script-el adtunk meg. Ezeknek elsősorban nem folyamatindítás a céljuk, sőt nem is képesek erre, hanem a céljuk a környezet előkészítése a futtatás előtt, és a takarítás a futtatás után. A pre-start script meghatározza a shell kódot, melyet a fő folyamat előtt futtatunk. Hasonlóan mint a script-nél amennyiben nem sikerül valamelyik parancs végrehajtása, a script futása lezárul.

pre-start script
    #prepare environment
    mkdir –p /var/run/foo
end script

A post-stop script meghatározza azt a shell kódot aminek le kell futnia egy folyamat befejeződése vagy terminálódása után. Hasonlóan, mint a script-nél, ha valamely parancs meghiúsul, akkor a script terminálódik.

post-stop script
	#  clean up
	rm –rf /var/run/foo
end script

9.1.3 Start on és stop on

Az elsődleges eseménye az upstart-nak a startup, ami számítógép indulásakor lép fel mielőtt van írható fájlrendszer, illetve hálózat.

Amennyiben példa job-okat használunk, azok rendelkeznek runlevel-x eseményekkel, ahol az x 0-6 vagy S lehet. A job-ok futni fognak az adott futási szint mellet.

Lehet olyan eset, amikor a folyamatok akkor generálnak eseményeket, amikor azok futnak, de előfordulhat az is, hogy akkor futtatjuk a folyamatunkat, amikor egy másik job leállt. Ezt a stopped job-bal, vagy started job-bal tudjuk megadni. A start on-nal vagy stop on-nal tudjuk meghatározni, hogy az eseményekkor elinduljanak vagy leálljanak a job-ok.

start on startup
start on runlevel [23]
start on stopped rcS
start on started tty1

9.1.4 Console

Meg lehet változtatni, hogy a job kimenete hova menjen, vagy honnan fogadjon bemenetet. Ezt a console strófával tudjuk megadni, ez lehet output, owner vagy none (ez az alapértelmezett, a bemenet és a kimenet a /dev/null-ra megy)

exec echo example
console output

9.2 Job control


A munkákat kézzel lehet indítani vagy leállítani a start vagy stop parancs segítségével, melyek általában a /sbin könyvtárban találhatóak. Mindkét parancsnak meg kell adni a job nevét, ami outputként visszaadja az adott job állapotát.

# start tty1
tty1 start/running, process 7490

# stop tty1
tty1 stop/running, process 7490

9.2.1 Status

Egy munka állapotát a status paranccsal lehet lekérdezni, mely szintén a /sbin könyvtárba van általában telepítve.

# status tty1
tty1 stop/waiting

# start tty1
tty1 start/running, process 4418

# status tty1
tty1 start/running, process 4418

A kimenet a következőképpen értelmezhető, job név, melyet az állapot követ, az állapot után pedig a process id következik.

9.2.2 Initctl list

Kilistázza az összes munkát, és az állapotukat.

# initctl list
control-alt-delete stop/waiting
rc stop/waiting
rc-sysinit stop/waiting
rcS stop/waiting
tty1 start/running, process 4418
tty2 start/running, process 7367
tty3 start/running, process 7368
tty4 start/running, process 7369
tty5 start/running, process 7370
tty6 start/running, process 7371

9.2.3 Initctl emit

Egy saját eseményt lehet kibocsátani az initctl emit parancs segítségével. Az összes job-ot érinti az esemény mely indulna vagy leállna. pl:

start on bounce
exec echo --Bounced--
console output

A job-ot pedig a következőképpen futtathatjuk le:

# initctl emit bounce
# --Bounced—

Az események átvehetnek paramétereket.

9.3 Saját script írása


A vizsgálat során megpróbálkoztam saját scriptet írni. A script nem bonyolult, csak egy szöveget ír ki megadott eseményre. A következőképpen néz ki:

start on started tty1
exec echo Have an ice day
console output

Amikor a tty1 elindul, akkor kiírja a képernyőre a Have an ice day feliratot.

9.3.1 Paraméterek használata

Az események több, mint egy környezeti változót tartalmazhatnak, és több mint egy egyezés is lehetséges.

start on weather KIND=rain INTENSITY=heavy

Az egyezésesk balójában globok, szóval használható a *, a ? az =, és természeten a !=. Ezek közül hasznos az utóbbit a stop on strófában használni, természetesen a többi strófában is lehet alkalmazni, ahol szükség van rá. Használatára egy példa, melynek neve legyen example.conf

start on weather KIND=rain or weather KIND=snow
stop on weather KIND!=$KIND

A példában először elindítjuk a job-ot, melynél weather eseményt illesztjük a $KIND-dal, melynek értéke rain vagy snow. Ezután biztosítjuk a feltétet, a job megállítására, ahol ismét a weather eseményt illesztjük a $KIND értékével, csak most saját magával illesztjük. Vizsgáljuk meg a futás eredményét:

# status example
example stop/waiting

# initctl emit weather KIND=rain
# status example
example start/running

# initctl emit weather KIND=sun
# status example
example stop/waiting

9.4 Started, Stopped, Starting, Stopping


Vegyük például a következő sort:

start on started dbus

A fenti példában a started az esemény nevét, míg a dbus az első paraméter értékét jelenti. Ha megnézzük a man 7 started-et, akkor megtekinthetőek lesznek a környezeti változók, és azok sorrendje.

started JOB=JOB INSTANCE=INSTANCE [ENV]... 

Látható, hogy a started dbus alkalmazásakor nem lett kiírva a változónév, mivel rövidítést alkalmaznak. A man-nak megfelelően alkalmazhatjuk ezt a leírást is:

start on started JOB=dbus

Elgondolkodtató, hogy mekkora különbséget jelent az átírás. Egy jó példa a stopped esemény exploitolása. Ha megnézzük a man 7 stopped oldalt, látható, hogy mennyi környezeti változóval rendelkezik, amely nem csak azt határozza meg, hogy mely job állt le, hanem azt is, hogy mi volt az oka a leállásnak. Ezek közül az egyik például az exit signal.

Ennek tudatában bármely környezeti változót párosíthatunk az eseményben. Egy példa arra, hogyan futtathatunk egy script-et, amennyiben bármely esemény szegmenációs hibával kilép:

start on stopped EXIT_SIGNAL=SEGV

Lehetséges az is, hogy egyáltalán nem párosítunk változót, csak az első paramétert használjuk. Ilyen esetben a starting eseményblokkot remekül ki lehet használni. A starting eseményblokkja a megnevezett feladatot ténylegesen elindítja, amíg a started bármit el nem kezd futtatni, vagy addig, amíg a megjelölt task be nem fejeződik.

Íme egy job, mely mindig lefut, amikor a task job elindul, illetve blokkolja azt, amíg a script be nem fejeződik.

start on starting task

script
    ....
end script

Ez használható debuggolásra illetve teljesítményanalízisre.

Eddig azokat a környezeti változókra koncentráltunk, melyek az események felől érkeznek, és amelyeket az upstart az job eseményekbe helyez. De ezeket tudjuk igen hasznos módon befolyásolni. Elsőként deklarálunk egy default értéket egy job-ban található környezeti változónak, ha nincs egyéb érték megadva ennek, a start esemény vagy parancs által, akkor ez az alapértelmezett érték nyer.

start on mounted
env MOUNTPOINT=/tmp
script
    ....
end script

Ez a script le fog futni minden egyes mounted esemény során, és remélhetőleg megkapjuk a $MOUNTPOINT értékét ettől az eseménytől.

10 Tesztek

A tesztelés során virtualboxon hoztam létre virtuális gépeket, és ezeket vizsgáltam. Minden virtuális gépnek ugyanolyan futási környezetet állítottam be az egységesség érdekében.

10.1 Telepítés Debianra

Az upstart jelenleg a debian 5.0 változatában még nem található meg. Próbáltam telepíteni forrásból, de számtalan csomagtól függött, melyeknek a begyűjtése, és telepítése eléggé körülményes lett volna, ezért ezt a megoldást elvetettem. A debian squeeze-ben viszont megtalálható az upstart, így a meglévő rendszer csomaglistájához beimportáltam a testing csomagokat is. A rendszer csomagjainak frissítése után nekiálltam az upstart telepítésének. A telepítés első lépése az volt, hogy eltávolítottam a sysvinit-et. Az eltávolítás után pedig minden további nélkül sikerült feltelepíteni az upstart-ot. Az újraindítás során az upstart vette át az indítási folyamatot, azonban számottevő gyorsulás nem következett be, mivel a sysvinit scriptjeit importálta az upstart a telepítés során. Ahhoz, hogy nagyobb gyorsulás következzen be, az init scripteket újra kéne írni.

A /etc/init könyvtárban találhatóak az indítási scriptek és konfig fileok, melyek a következők:

  • control-alt-delete.conf, meghatározza, hogy mi történjen ezen billenytyűkombináció megnyomásakor
  • dbus-reconnect.conf, a D-Bus-hoz történő újrakapcsolódást végzi
  • rc-sysinit.conf, a régi sysvinit scriptek futtatását végzi
  • rc.conf, runlevel váltásért felelős
  • rcS.conf, sysvinit szkriptek futásáért felelős egyfelhasználós módban
  • tty1.conf, getty futásáért felelős.

...

  • tty6.conf, getty futásáért felelős

Próbáltam feltelepíteni az apache2-t, azonban még hagyományos init scripttel rendelkezik. Ahhoz, hogy a teljes átállás megtörténjen, még sok időnek kell eltelnie.

10.2 Debianon az init scriptek

control-alt-delete.conf
dbus-reconnect.conf
proba.conf
rc.conf
rc-sysinit.conf
rcS.conf
tty1.conf
tty2.conf
tty3.conf
tty4.conf
tty5.conf
tty6.conf

Látható, hogy csak a legszükségesebb scriptek vannak az upstart-ba áthelyezve, a többi folyamatot sysinit scriptjei kezelik. Remélhetőleg idővel ez a lista megnövekszik hasonlóan, mint az ubuntunál.

10.3 Ubuntun

atd.conf
console-setup.conf
control-alt-delete.conf
cron.conf
dmesg.conf
hostname.conf
hwclock.conf
hwclock-save.conf
irqbalance.conf
module-init-tools.conf
mountall.conf
mountall-net.conf
mountall-reboot.conf
mountall-shell.conf
mounted-dev.conf
mounted-tmp.conf
mounted-varrun.conf
networking.conf
network-interface.conf
network-interface-security.conf
nmbd.conf
plymouth.conf
plymouth-log.conf
plymouth-splash.conf
plymouth-stop.conf
procps.conf
rc.conf
rc-sysinit.conf
rcS.conf
rsyslog.conf
smbd.conf
ssh.conf
tty1.conf
tty2.conf
tty3.conf
tty4.conf
tty5.conf
tty6.conf
udev.conf
udev-finish.conf
udevmonitor.conf
udevtrigger.conf
ufw.conf
upstart-udev-bridge.conf
ureadahead.conf
ureadahead-other.conf

Érdekesség, hogy az ubuntura telepítettem az apache2-t, azonban az init scriptek között nem szerepel, ez amiatt lehetséges, hogy az apache2-höz még nincs upstart-os init script, így még a sysvinit-es betöltést használja.

11 Debugging

Ebben a fejezetben azt vizsgálom meg, hogyan lehet az upstart eseményekkel kapcsolatos hibákat, rendellenességeket feltérképezni.

Legegyszerűbb hibalehetőség, ha egy program telepítése után nem indul el valamilyen oknál fogva. Például egy webszervert telepítünk, és azt szeretnénk, hogy minden egyes boot során elinduljon. Elsőként a /etc/init könyvtárat célszerű megvizsgálni, hogy megtalálható-e benne a programunk indításához szükséges *.conf fájl. Amennyiben ez hiányzik, akkor valószínűleg még a régi init indítási scriptet használja. Ebben az esetben meg kell vizsgálni, hogy a telepítés során létre jött-e a hagyományos init indítási script. Ha nem jött létre valamilyen oknál foga, akkor nincs más lehetőség, hogy be kell szerezni, vagy írni kell a programunknak egy indítási scriptet.

Amennyiben megtalálható az konfigurációs fájl a /etc/init könyvtárban, akkor azt kell megvizsgálnunk, hogy milyen állapotban van a job-unk. Az initctl list paranccsal kilistázhatjuk a rendszeren lévő job-okat. Ha a listában nem található meg az indítandó folyamat, akkor a konfigurációs fájllal lehet probléma, elképzelhető, hogy csak gépelési hiba történt, és emiatt nem jelenik a job a listában. Ha a job megjelenki, azonban a stop/waiting feliratot látjuk mellette, akkor az azt jelenti, hogy a konfigurációs fájl jó, azonban a job vagy nem indult el valamiért, vagy már lefutott. Például egy szervernek folyamatosan futnia kéne, nem pedig lefutott állapotban kell lennie, így valószínűleg az indító eseményt nem kapta meg a folyamat. Ennek ellenőrzésére használható az a módszer, amit fentebb már kifejtettem. Elsőként megvizsgáljuk a konfigurációs fájl start on mezőjét. Létrehozunk olyan konfigurációs fájlokat, melyek akkor futnak le, amikor a követelmények elindulnak, vagy elindultak. Ezek a például pedig azt tegyék, hogy a /tmp könyvtárban létrehoznak fájlokat, melyekbe üzeneteket írunk. De elegendő az is, hogy olyan beszédes fájlneveket használunk, és ez már információval bír. Például:

start on net-device-up
exec touch /tmp/net_up

Az is megoldás lehet, ha starting strófát használjuk, mivel akkor meg tudjuk állapítani, hogy egyáltalán indulófélben van-e a folyamatunk. Pl.:

start on starting ssh
exec touch /tmp/ssh_start

Lehetőség van arra is, hogy módosítjuk az indítási scriptet oly módon, hogy kiegészítjük a start on mezőjét úgy, hogy hozzáveszünk egy általunk definiált eseményt. Ezután manuálisan meg lehet próbálni elindítani a programunkat. Pl.:

start on starting ssh or indulj
exec touch /tmp/ssh_start

Ebben az esetben az initctl emit indulj paranccsal el tudjuk indítani a scriptünket. Ha így nem indul el a program, akkor az indítási scriptet kell módosítani, mert azzal lehet probléma. Ha elindul, akkor szinte biztos, hogy a script a futtatásához szükséges eseményeket nem kapja meg. Ennek orvoslására az előbb leírt módon meg kell vizsgálni, hogy melyik esemény nem generálódott le, vagy másik lehetőség, ha módosítjuk a konfigurációs fájlt oly módon, hogy például olyan program után indítjuk a programunkat, ahol a programunk futásához szükséges feltételek biztos, hogy rendelkezésre állnak. Pl.:

start on stopped rc
...

Az rc futtatja le a hagyományos init scripteket, így, ha az rc lefutott, akkor nagy valószínűséggel a mi programunkhoz szükséges feltételek is rendelkezésre állnak.

12 Összegzés

Az upstart egy jól, és könnyen használható init eszköz lesz a jövőben, hátránya még az, hogy nem teljesen kiforrott, például a fájlformátumok még alakulnak. Ahogy a csomagfejlesztők egyre inkább kezdenek átállni az upstart-os init scriptek alkalmazására, úgy egyre inkább teret fog nyerni a jelentőssége, ami elsősorban nem a gyorsaságában fog kitűnni, hanem a rugalmasságában és átláthatóságában.

13 Felhasznált irodalom

Upstart, Upstart getting started, Upstart in universe, Wikipedia, Event matching in upstart, Started man page, Stopped man page, Starting man page, Stopping man page, Init man page

Személyes eszközök