Jako mírně zkušeného uživatele Linuxu mě děsí, že bude init nahrazen nějakým komplikovaným molochem. Co když budu potřebovat něco upravit? Bude to stejně tak jednoduché? A stojí tolik práce a navýšení komplexnosti (tj. i chybovosti, udržovatelnosti, ...) řešení za těch 10 sekund při bootu???
On se opravdu někde používá jen init? Co já vím, ve skutečnosti je init tak „jednoduchý“, že už dávno nestačí a jen spouští jiný proces, který se teprve stará o skutečný start služeb systému. Mně vůbec nejde o nějakých deset sekund při bootu – já budu spokojen, když konečně nebudu mít v systému dva správce služeb, ale jen jednoho.
Skript nestačí. Potřebujete něco, co ten skript při startu systému spustí. Tedy nějakého správce těch služeb – původně to byl init (proto jsou tam ty runlevely apod.). Postupně se ukáže, že je dobré, když se ten správce umí nějak postarat o závislosti služeb – nejprve tak, že je administrátor seřadí a správce je spouští postupně v určeném pořadí, později ten správce uměl pořadí podle závislostí stanovit sám. Také je dobré, když se ten správce umí o službu postarat i v průběhu běhu té služby – třeba spravovat logy nebo službu znovu spustit, pokud se ukončí. To znovuspuštění třeba uměl už sysvinit, ale správce založený jen na spouštění rc-skriptů o tuhle schopnost přišel.
> Potřebujete něco, co ten skript při startu systému spustí.
# Start daemons
for daemon in "${DAEMONS[@]}"; do
case ${daemon:0:1} in
'!') continue;; # Skip this daemon.
'@') start_daemon_bkgd "${daemon#@}";;
*) start_daemon "$daemon";;
esac
done
kde teda start_daemon zavola /etc/rc.d/"$1" start. Koniec citatu z poslednej pricetnej verzie Archovskeho initu :)
Vsetko ostatne (spravovat logy? samoukoncujuce sa sluzby?!) je otazkou utilit, ktore v ziadnom pripade do initu nepatria.
Už tenhle skript je ale jeden nástroj navíc. Původně měl správu služeb zajišťovat init, s tím vaším skriptem už na to máte dva nástroje – nejprve init, a pak tenhle váš skript. Takže sysvinit asi neumí to, co se po něm dnes požaduje, když je nutné ho něčím doplňovat.
Samoukončující se služby jsou všechny služby – u každé služby může dojít k chybě, kvůli které se služba ukončí. Nastartovat službu, která se ukončila, umí i sysvinit – pokud to podle vás umět nemá, stěžujte si jeho autorům, že je to příliš velký bumbrlíček, který dělá i věci, které po něm nikdo nechce…
Ten skript je len funkcia z inicializacneho skriptu Archu. Nieje to ziaden nastroj, len to len kod, ktory nikto pricetny nebude z bashu prepisovat do cecka.
So sysvinitom sa, pokial viem, vzdy pouzivaju rc.d skripty, takze si neviem predstavit, ako by init vobec zistoval, ze sa nejaka sluzba zastavila.
Což je poněkud smutné vysvědčení pro nástroj, který je pro spouštění služeb určený.
Takže když už teď víme, že init nedělá zrovna nejlépe to, k čemu je určený, je nutné to dobastlovat různými skripty, které také nefungují zrovna perfektně, proč nenapsat nový nástroj, který to bude dělat lépe? No, a přesně takhle vznikly Upstart, Runit nebo Systemd.
> Což je poněkud smutné vysvědčení pro nástroj, který je pro spouštění služeb určený.
> Takže když už teď víme, že init nedělá zrovna nejlépe to, k čemu je určený
sysvinit. Sys-V-init. System 5 Init. Nastroj pre inicializaciu systemu. Robite si zo mna srandu?
Vsetko po inite, vratane spustenia sluzieb sa robi skriptami jednoducho preto, lebo to jednoduchsie spravit nejde. Skripty sa daju v pripade potreby jednoducho prisposobit a spravcovia balickov maju pekny zvyk prisposobene skripty neprepisovat. Skuste si prisposobit systemd tak, aby Vam to prezilo update :)
Místo žonglování se jménem si raději přečtěte popis, co sysvinit dělá. Sysvinit je nástroj pro spouštění a správu procesů. Není žádný principiální důvod spouštět některé procesy jedním nástrojem a další jiným. Důvod, proč se to tak dnes s sysvinitem dělá, je jednoduchý – sysvinit na dnešní požadavky nestačí.
Pomocí skriptů nemusíte spouštět jen nějaké služby, klidně můžete celý sysvinit nahradit skriptem. Akorát by se to špatně používalo.
Je potřeba rozlišovat dvě věci. Náhrada dvoj-initu sysvinit+rc-* skripty jedním schopnějším initem – o to se snaží víc projektů. Sám jste napsal, že na spouštění služeb není sysvinit vhodný a ani vás nenapadlo používat jej v původní podobě, bez doplnění skripty.
Druhá věc je místo imperativního popisu co jak spustit, zastavit restartovat apod. používat deklarativní popis, který se mnohem snáze kontroluje a vyhodnocuje. Při příležitosti náhrady initu je to dobrá příležitost změnit i tohle. Někomu se to nelíbí, někdo jiný je zase rád. Skripty sice umožňují přizpůsobit se zvláštnostem každého programu, já ale nevidím důvod, proč by se každý program měl startovat jinak, proč by se měl chovat jinak při spuštění z příkazové řádky a ze správce služeb apod. Já třeba některé služby už dávno spouštím pod daemontools od DJB, který k tomu měl podobný přístup. Služba má běžet na popředí, výstupy vypisovat na standardní výstup a běžet s právy, se kterými byla spuštěna. Ukončit se má signálem SIGINT. O logování výstupu, změnu efektivních práv, nastavení limitů, zastavování a spouštění služby se pak má starat správce služeb. Je to pohodlnější pro správu takových služeb, je to dokonce jednodušší i pro programátora takové služby. DJB to řešil skriptem, ale výše uvedené se dá snadno nakonfigurovat i v nějakém konfiguračním souboru.
> Sysvinit je nástroj pro spouštění a správu procesů. Není žádný principiální důvod spouštět některé procesy jedním nástrojem a další jiným.
> Důvod, proč se to tak dnes s sysvinitem dělá, je jednoduchý – sysvinit na dnešní požadavky nestačí.
Zial, zjavne si pod Sysvinit-om nepredstavujeme obaja to iste (co je mimochodom dost zvlastny ukaz :p) Sysvinit pravdepodobne nikdy k spustaniu sluzieb nesluzil, uz v dobach system5 koncil u /etc/rccosi a gettty. Dovodom bol klasicky KISS princip - je ovela menej nachylne na chyby, ak init spravi len najnutnejsiu inicializaciu a skriptovanie necha na [ba|z|c|t]sh. Krasnou ukazkou toho bol rok 2012 za Archom, kde uspesny boot po update predstavoval dobry dovod otvorit flasku a neuspesny zasa flashku -_-
> Pomocí skriptů nemusíte spouštět jen nějaké služby, klidně můžete celý sysvinit nahradit skriptem. Akorát by se to špatně používalo.
Preco? Arch tak (minimalna binarka initu, *vsetko* ostatne bash) fungoval este minuly rok a nie som jediny, kto tak v pohode funguje dodnes.
> Sám jste napsal, že na spouštění služeb není sysvinit vhodný a ani vás nenapadlo používat jej v původní podobě, bez doplnění skripty.
Kde? :)
Co tedy váš sysvinit dělá jiného, než že spouští služby? Můj init má v manuálové stránce hned u názvu napsáno „process control initialization“ a v popisu pak „Init is the parent of all processes. Its primary role is to create processes from a script stored in the file /etc/inittab. This file usually has entries which cause init to spawn gettys on each line that users can log in. It also controls autonomous processes required by any particular system.“
Pokud by jedinou funkcí initu bylo spustit getty pro jednotlivé terminály a pak spustit nějaký další skript, k čemu tam jsou třeba runlevely?
Říká to o initu, že je to nástroj na spouštění a správu procesů (dnes se procesům spouštěným při startu většinou říká služby, dříve se jim také často říkalo démoni, podle toho, že běžely na pozadí). Není tam nic o tom, že je to nástroj pro spuštění getty a předání řízení nějakému dalšímu nástroji pro správu procesů.
A co ked ${daemon#@} naforkuje child procesy a sam sa ukonci (alebo zhuci)? Ako dokaze init stopnut takuto sluzbu?
Nedokaze. Dokaze to len ten zly zly systemd, ktory jednotlivych demonov oddeli do control groups a ked treba sluzbu zastavit, zastavi vsetko v danej control grupe.
A to je len priklad, kde systemd nieco riesi systemovo, kde sa doteraz pouzivali rozlicne hacky.
Spíš systemd standardizuje jeden z hacků. Někteří považují takové chování démonů za chybné už asi 20 let a tvrdí, že správným řešením je oprava takového programu.
System ma taku chybu hlasit, nie sa snazit riesit ju automaticky. Cize presne to, co robi klasicky rc skript.
Systemd ma tendenciu poziadat sluzbu, aby sa vypla a vzapati zamordovat vsetky jej procesy. Takze ak mi napriklad FTP server hlasi, ze uzivatel backup prave uploaduje a on ho ma zakazane odpajat, pokial doslova serverovna nehori, systemd zahlasi "iste" a zakilluje proces.