Upstart 1.0

Szerszám

Scott James Remnant bejelentette az Upstart névre hallgató rendszerindító mechanizmus 1.0-s verzióját. Az Upstart az Ubuntu háza tájáról indult valamikor 2006-ban. Időközben átvette a Fedora, az openSUSE, a Debian és a Red Hat Enterprise Linux is. A fejlesztő azt javasolja minden upstart-ot használónak, hogy frissítsen 1.0-ra.

[ weboldal | bejelentés ]

( bimi3 | 2011. 03. 03., cs – 12:48 )

"azt javasolja ... frissítsen 1.0-ra"

Minek? A mostani is felhúzza a rendszert. Ennél többet nem kell tudnia.

( godot v | 2011. 03. 03., cs – 14:26 )

Még mindig kézzel kell belepiszkálni a conf fájlba ha le akarok tiltani egy szervízt? Egy éve itt tartott a tudomány.

Az upstart-ra átírt szervizekre ez nem igazán működik.

Lássuk csak 10.04LTS

sudo apt-get install vsftpd
Beállítás: vsftpd (2.2.2-3ubuntu6) ...
vsftpd start/running, process 1988

ls -l /etc/init.d/vsftpd
lrwxrwxrwx 1 root root 21 2011-03-03 14:47 /etc/init.d/vsftpd -> /lib/init/upstart-job

Az /etc/rc*.d könyvtárakban nincsenek szimlinkek.

ls -la /etc/rc*.d | grep vsftpd

sudo update-rc.d -f vsftpd remove
Removing any system startup links for /etc/init.d/vsftpd ...

Reboot után ugyanúgy megy.

Le kell törölni a /etc/init/vsftpd.conf fájlt, vagy módosítani. Ami LOL.
2009 óta histiznek ezért sokan.

Olyanra gondolok, mint Redhatban a

chkconfig service off,on

Másik kedvencem:

https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430224

chroot-ban nem működik az upstart
Aki sokat feljeszt és futtat chroot-ban démonokat annak ez nagyon fáj.

Szóval 10 éve nem létező problémákat generáltak. :)

Az upstart valóban gáz. Bár tapasztalatom alapján nem is annyira maga az upstart-tal van baj, hanem inkább az init-ről upstart-ra való átállással. :-(

Eddig csak szívtam vele, gyakorlati előnyt (amitől könnyebb lett volna az életem) nem tapasztaltam. Szinte mindegyik Ubuntu upgrade-nél bejött valami új hiba az upstart-ra való átállásnak köszönhetően. Általában két v. több komponens indítása során kialakult versenyhelyzet miatt, ami szebbnél szebb hibákat tud produkálni (pl. egyáltalán nem indul el a rendszer ... v. nem indul el az NFS szerver (v. a kliensen nem megy a mount) ... v. látszólag minden NFS komponens jól elindul (semmi sem dob hibát), de a kliensek nem tudják felcsatolni a megosztott könyvtárakat, mert a statd a portmap előtt indult el, aminek nagyon nem örül ... és még sorolhatnám). A launchpad.net tele van upstart-ból eredő hibákkal és jó sokat már évek óta "javítanak". Sajnos az átállás nagyon szakaszos, így egy csomó hiba abból ered, hogy ezt+azt már átírták upstart-ra, de az xy komponenst még nem és ha ezek a boot során egymástól függenek, akkor tutira valami nem megfelelő sorrendben fog történni.

Egyébként nekem nagyon úgy tűnik, hogy az upstartot a desktop OS-ek számára készítették (a default desktop telepítéshez fejlesztik és azon tesztelik), a szervert futtató ember meg csak szív miatta. Valószínűleg az elsődleges célja az volt, hogy a linux alapú desktop rendszerek indulási ideje is legalább olyan gyors lehessen, mint mondjuk egy Windows 7 esetében. Ezért egy olyan rendszerindítóra volt szükség, amiben az egyes részfolyamatokat indító scriptek között (akár bonyolult) függőségeket lehet definiálni, aminek következtében a scriptek párhuzamosan futhatnak és a teljes folyamat (boot) ideje masszívan lerövidülhet.

Összességében az upstart (v. hasonló, eseményalapú "fővezérlő program" :-) ) bevezetése elkerülhetetlen volt, csak éppen úgy érzem, hogy túl sokáig tartott és az Ubuntu által hirdetett visszamenőleges kompatibilitás és a könnyű/problémamentes upgrade nem igazán valósultak meg (mondhatni sokáig más se látszott az upstart-ból, mint az upgrade okozta problémák).

ui: persze jogos kérdés, hogy miért akar valaki (pl. én) Ubuntu szervert üzemeltetni. :-) Esetemben ez bizonyult a kisebbik rossznak a lehetőségek közül (lásd: linux terminál szerver - LTSP).

Ezzel nagyon vigyázni kell.

Én szerettem régen a sysv-rc-conf-ot használni a szolgáltatások ki-bekapcsolására. Fejlesztéshez van a gépemen belőve egy gyenge jelszóval védett adatbázis-szerver, amit csak saját tűzfallal védett hálózatokon kapcsolok be.

Na, ezzel az upstartos átállással sikerült úgy megszivatnom magam, hogy kikapcsolatam a sysv rendszerben a szolgáltatást, és nagy mellénnyel gondoltam, hogy így felmehetek publikus hálózatokra. Egyik ismerősöm szólt, hogy figyelj már, karácsonyfa a géped. Így tudtam meg, hogy mostantól conf fájlban kell leállítani a szolgáltatásokat.

Ahogyan mások is jelezték, nem fog menni. Ma viszont a Ubuntu 11.04 alpha3 bejelentésében olvastam valamit, ami megoldás lehet egy adott szolgáltatás automatikus indításának letiltására:

"A new job configuration stanza, "manual" has been added. If specified, this has
the effect of removing any previously defined "start on" stanza for job so that
the job can only be started with "initctl start" / "start".
This is most useful when used in combination with Override files.

Override Files

Override files are files ending in ".override" which if placed into
the job configuration directory ("/etc/init/") are able to modify the
way in which a job configuration file behaves. They could be used by
System Administrators or tooling to change the behaviour of a job
without modifying a packages configuration files directly.

Override files support the same syntax as the existing job configuration
(".conf") files.

For example, to ensure that a service is never automatically started:

echo manual >> /etc/init/myjob.override

To allow the original behaviour, simply delete the Override file.

Another example: to change the start on condition for a job:

echo "start on (starting job-A or event-B)" >> /etc/init/myjob.override

Note that Override files have no effect unless there is a corresponding
job configuration file (a file with the same prefix name).

The effect of deleting an override file is to revert the job (immediately)
back to its original configuration."

Részletek az Ubuntu Natty Alpha3 bejelentésben: http://www.ubuntu.com/testing/natty/alpha3

Magam nem próbáltam ki.

( nightw | 2011. 03. 03., cs – 15:04 )

Bizonyára az én hibám, de nem szeretem ezt a stuff-ot. Értem, hogy többet tud, mint az init, ami nagyszerű, de pont nem tudja a legalapvetőbb dolgokat, amik miatt az init-et ki kellett volna már baszni 5 évvel ezelőtt. Nagyszerű, hogy eventeket kezel, amivel a storage device-oknak olyan nagyon jó. De igazából röhej, hogy egyszerűen csak ennyit ad pluszban és kész. Nem tudom elképzelni, hogy aki annak idején új init rendszer irásába fogott, az nem volt képes megnézni, hogy mit tudnak a többiek. Ha látta volna az SMF-et, akkor például biztos lenne benne egymásra függés és sorrendezés meg például automatikus service újraindítás, ha valami leáll. Ezek nélkül én egyszerűen nem tudok elképzelni normális init rendszert és most jó pár évre be lett betonozva ez a dolog az upstart elterjedésével egy alig jobb szintre.

"Ezek nélkül én egyszerűen nem tudok elképzelni normális init rendszert és most jó pár évre be lett betonozva ez a dolog az upstart elterjedésével egy alig jobb szintre."

Nekem úgy tűnik, hogy nincs bebetonozva semmi. Folyamatosan megy az útkeresés és úgy tűnik, hogy a Fedora a következő verziójában már kísérletezik a systemd-vel. Az openSUSE szintén.

--
trey @ gépház

"Ha látta volna az SMF-et, akkor például biztos lenne benne egymásra függés és sorrendezés"
Látta, és direkt nem akarta. Ha elovastad volna a leírást, akkor tudnád, hogy evil dolognak tartják a függőséget, az egyetlen igaz üdvözítő út az event alapú akkor-töltsd-be-mikor-először-kell. Megmondták.

( kaltsi | 2011. 03. 04., p – 11:09 )

Én csak azt nem értem, ha ilyen sz*r, akkor miért váltott sok distro erre?
Lassan minden szolgáltatást beleintegrálnak, ha a régi inittab és rc.* jobb volt és ez semmiben sem több és még bug-os is, miért teszik?

A dokumentálást hiányolom, mert amik vannak hozzá elég szűkszavúak.
Ha egy init ismeretlen állapotba kerül, csak az újraindítás veszi ki a listából.
Tény vannak hiányosságai, gondok vele, de használható.