Ano a podla vas kde ma systemd smerovat? aby uspokojil 0.1% ludi co su puristi a 0.1% ludi co z principu odmietaju vsetko nove? Ak su tam chyby treba ich fixnut ale bezneho pouzivatela sa toto v najmensom nedotkne. To, ze vy vydavate vzorku root.cz a ine linux stranky za nejaku smerodajnu vzorku je mimo navyse clovek v principe skor pise ked mu nieco nejde ako ked mu to funguje. Takze pomerovat podla toho ci je nieco ok alebo nie je usmevne.
PS: Guix som si nepozeral a ani to nevidim dovod. Potrebujem linux na pracu a nie skumat ci stromy v kerneli su implementovane pomocou redblack stromov alebo inac. Podobne sa ma nedotyka systemd vs init okrem toho, ze vzdy ked som si potreboval rucne upravit nejaky servis co spustal veci v java tak ma pekne stval cely ten system zazracneho kontrolovania ci cosi bezi, nebezi a co asi tak by sa malo urobit. Samozrejme co verzia (Centos, Fedora) to trocha ine scripty. A to Fedora a centos maju aspon nejaky vztah.
Ale jasne, nebudme "puriste", at si kazdej proces placa konfiguraci kde jen chce! Kdyz ji systemd muze mit nekde /usr/lib/, pak treba network at je nekde ve /var/eth a sshd ji muze mit treba v /sbin/ssh.
Proc bychom meli mit vsechno prehledne v etc, vzdyt nejsme puriste! Tech 40-50 lokaci kde vsude bude zalezla konfigurace si kazdej jiste snadno zapamatuje. FHS je jen pro "puristy", toho se predce my nebudem drzet!
ale jasne ze ma...
/etc/systemd/system:
dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service
dbus-org.freedesktop.Avahi.service -> /usr/lib/systemd/system/avahi-daemon.service
dbus-org.freedesktop.NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service
default.target -> /lib/systemd/system/graphical.target
...
..
.
nasymlinkovat sa to da aj do /tmp
Nečetl jste příspěvek, na který reagujete. V tom přísvěvku byl základní "RH" argument typu "chci s tím pracovat a v tomto rámci si to i nastavit, ale nechci se vrtat v nákladních systémových procesech". Nejde o ignoranci, ale o odlišný profil uživatelských priorit. Udělat si o někom subjektivní představu a vydávat to za princip je vskutku dost ujeté...
A to je právě to. Proč hledat alternativu k systémům které systemd obsahují? Ano, možná se zdá systemd složitý, ale na rozdíl od jiných svobodných projektů má alespoň dokumentaci a poměrně dobré manuálové stránky, což se například o různých ConsoleKitech, PackageKitech (které se taky pěkně infiltrovali do spousty distribucí) říci nedá.
Co to je za nesmysl, že se alternativy „nedají používat?“ Gentoo používáme ve stovkách instalací, od produkčních serverů až po desktopové stanice (pravda, ne „kancelářská PC“, ale trochu specifické použití), k plné spokojenosti, bez nějakého hackování.
Jediná věc, která mi v OpenRC zatím schází, je supervising služeb (když spadne, tak aby se ji pokusil znovu spustit). A to není nic nějak složitého, co by se do něj nedalo doplnit.
Uznávám, že Gentoo není úplně pro každého, ale rozhodně bych to neoznačil za něco „co se nedá používat.“
Jediná věc, která mi v OpenRC zatím schází, je supervising služeb (když spadne, tak aby se ji pokusil znovu spustit). A to není nic nějak složitého, co by se do něj nedalo doplnit.
Mně tohle připadá jako klíčová vlastnost pro systém na správu služeb. Trochu jako kdyby webový prohlížeč uměl posílat e-mail, telefonovat a stahovat z FTP, akorát mu chyběla taková drobnost, jako podpora HTTP.
Správa služeb rozhodně žádná data nezničí, to může udělat nanejvýš špatně napsaná služba – a takovou službu správce nemusí nechávat automaticky znovu spouštět. Kvůli tomu, aby se administrátor podíval, proč služba spadla, nemusí ta služba být vypnutá.
Mimochodem, restart ukončeného programu umí i init
, akorát že to (na rozdíl od jiných správců) není moc konfigurovatelné – a reálně se to používá jen pro getty
.
Da ze na to nainstalovat demon, kterej bude sam o sobe rozhodne spolehlivejsi, nez systemd, ale viz niz, kdyz neco zbuchne, je to treba spravit, a ne tu rozbitou vec poustet znova.
Problem gentoo je, ze uz je timhle svinstvem taky nakazeny. Trebas na udev tam uz jsou tusim nejaky patche, aby to svinstvo odparaly, ale otazka je, jak dlouho do bude maintainery bavit.
Gentoo je především o možnosti volby. Primární init systém je stále OpenRC, na tom se nic nezměnilo, jen přibyla možnost místo něj použít systemd.
Pracuje se na forku eudev, který je drop-in náhradou za udev (https://github.com/gentoo/eudev). Sám jsem ho zatím nezkoušel, ale co jsem četl, tak ho mnozí lidé již bez problémů používají.
Já došel k tomu, že na virtuálech udev vůbec nepotřebuju (zbytečný overkill) a přešel jsem na jednoduchoučký mdev z BusyBox (viz https://gist.github.com/jirutka/9496300). Na hypervizorech mám ještě udev, ale v dohledné době ho chci zkusit taktéž nahradit za mdev. Pokud by se to ukázalo jako příliš komplikované, tak zkusím eudev.
Ta možnost je ale trošku pokažená tím, že jsou situace, kdy ten podělanej systemd musím natvrdo zahardmaskovat, aby se mi tam nenatáhl. :-(
Nejde o USE flagy. Jde o to, že i s vypnutými příslušnými USE flagy a nainstalovaným balíčkem upower-pm-utils se ten bazmek pořád chtěl instalovat a nakonec pomohlo až to, že jsem ho natvrdo zapsal do package.mask. A evidentně potřeba nebyl, po zamaskování to nijak neprotestovalo...
Tak to je rozhodně chyba. Reportoval jsi to na https://bugs.gentoo.org?
Ne. Uvažoval jsem o tom, ale poté, co jsem si přečetl diskuse se správci příslušných balíčků na forums.gentoo.org, usoudil jsem, že a) už o tom stejně vědí a b) mám lepší věci na práci než se se svou mizernou angličtinou dohadovat s někým, komu jsou moje problémy (resp. problémy lidí jako já) evidentně fuk.
Jinak souhlas, když nějaká služba padá, je potřeba ji opravit, ne ji dokolečka spouštět znovu. To je jen řešení z nouze, leč občas se hodí. Nicméně chápu, že tvůrci systemd tuto funkci nezbytně potřebují, vzhledem k tomu, jaké sra*ky programují…
Navíc v seriózním nasazení má admin nad službami centrální monitoring, který mu výpadky zahlásí. A výpadek služby není jen to, že umře její proces, ale že se třeba HTTP rozhraní stane nedostupné, tudíž je totální kravina tohle řešit init systémem.
On se linux nepoužívá jen na enterprise serverech. Na nějakých „domácích“ serverech se nemusí nic dít, než se „admin“ za 14 dní vrátí z džungle a webserver znovu nastartuje. Ale je zbytečné, aby ten server 14 dní neběžel jenom proto, že jeden skript shodou okolností vyčerpal limit paměti.
Mimochodem, správu služeb i s tím znovuspuštěním služby umí třeba Daemontools od DJB, který to používá pro jeho balík TinyDNS. Neřekl bych, že by DJB programoval „sra*ky“, jak to nazýváte – akorát si asi nemyslí, že je vše dokonalé. Podobně se chová třeba aplikační server WebLogic – je tam node manažer, který hlídá běžící instance, a když se některá ukončí, nastartuje jí znova. Takže třeba když JRockit zvoře optimalizaci a padne na segfault, server za chvíli běží znovu. Jistě, správné řešení je pokusit se chybu zreprodukovat, nahlásit Oraclu a doufat, že vydají opravu – ale do té doby ten server klidně může běžet, ne?
Ostatně, na nastartování a zastavení služby nepotřebuju žádný speciální systém. Nastartuju jí jednoduše tak, že spustím příslušný program, a zastavím příkazem kill
. Správce služeb tedy není od toho, aby služby startoval a vypínal, ale od toho, aby udržoval v běhu ty služby, které mají být zapnuté.
Však jsem sám psal, že se to občas hodí. Třeba právě na takové případy, které zmiňujete. Nicméně nepovažuju to za klíčovou funkci init systému, bez které by se tomu nedal říkat init systém.
TinyDNS neznám, takže nemohu soudit. WebLogic bohužel trochu ano a to je zrovna příklad ultimátní sra*ky. Upozorňuji, že jsem java vývojář, takže za sra*ku to NEpovažuju automaticky jen proto, že je to psané v Javě.
Mně připadá, že bez té funkce to není žádný systém, bez toho máte jen sadu nějakých skriptů nebo konfiguračních souborů, které akorát určí, v jakém pořadí se má co nastartovat. Někomu to klidně může stačit. Jenže i ten původní SysVinit má respwan procesů, má runlevels, takže evidentně tam na začátku byla nějaká snaha, aby to fungovalo jako správce služeb. Akorát se od té doby trochu změnila doba a typická služba není terminál naslouchající na sériové lince, ale síťový server, který závisí na spoustě jiných služeb.
Já tedy vnímám systemd jako pokus, jak to, co musí být nad SysVinitem dobastleno pomosí spousty skriptů (a pak to zase neumí využívat ty původní funkce initu jako respwan), udělat jako jednu komponentu odpovídající dnešním požadavkům. Způsob implementace nebo nasazování může být sporný, ale k cíli, který systemd má, můžu říct jenom „no konečně“.
Stran akademickych kecu neco z realneho prostredi.
Na velkych infrastrukturach kde spravujes veci tretich stran, na kterych bezi veci ctvrtych stran fakt netusis co dana sluzba ma natahano a co ji muze vsechno shodit. Byvaji to kraviny jako chvilkove upadly link nebo chvilkovy timeout. Nez zburcujes vsechny po svete k analyze problemu, tak sluzba nebezi a stoji te to prachy.
Co je lepsi?
1. Uhnije mi sluzba a opet se sama nahodi. Sluzba bezi, zakaznik je spokojenej a technik mezitim resi analyzu coredumpu nebot mu pad sluzby byl zareportovan.
2. Sluzba 5krat rychle za sebou pri pokusech o nahozeni chcipne. Jelikoz system nedelal hlupak, tak po nastavenem poctu pokusu to vzda a spusti vyssi alarm na dohledu.
Takto nam treba funguje solarisi SMF. Muzete si i nastavit veci jako kdyz chcipne tahle sluzba tak naskoci tahle sluzba atp.
A nebo sluzba uhnije ale mohla by byt automaticky nahozena. Nez propadne call na dotycneho technika tak je minimalne pulhodina v haji ne-li, dele protoze clovek na druhe strane indovi nerozumel a vola primo na ops centrum. Vsechno stoji prachy...
Tim nerikam ze v pripade sluzeb kde je treba znat know how k jejich cistemu nahozeni a koordinovat to s jinymi tymy nema proste upadnuti sluzby smysl. Nicmene nemelo by se to naduzivat. Startovani pokud je to zadane ponechme strojum. Na blbou praci jsou dobri oni, lidem necht patri analyza.
Problém je v tom, že to programátor nenapsal dost robustně. Všechno ostatní jsou workaroundy a my se jen bavíme o tom, který je menší zlo. A tam se nám míchá názor provozovatele, názor administrátora, názor zákazníka a názor náhodného kolemjdoucího. Není překvapivé, že se neshodnou.
"Nez propadne call na dotycneho technika tak je minimalne pulhodina v haji ne-li, dele protoze clovek na druhe strane indovi nerozumel a vola primo na ops centrum."
"Problém je v tom, že to programátor nenapsal dost robustně."
Ve firmě, kde "call" na technika trvá půl hodiny a kde si jednotliví zaměstnanci vzájemně nerozumí, je také docela dobře možné, že to programátor nenapsal dost robustně, to zcela jistě.
Jak jsem psal, problém je v něčem zcela jiném, než v init systému.
Uhnije ti kabel k disku, sluzba zbuchne ... ty ji znovu nahodis, ona zapise ... poskodi cast dat ... a znova zbuchne ... a pak jeste petkrat ... takze data jsou v trapu. Pak muzes trebas 30 hodin obnovovat tyden stary backup ... to zakaznika jiste potesi. Jen kvuli tomu, ze startujes neco, co pada ...
Nemocné služby je přece potřeba opravit, jak tu bylo opakovaně napsáno. Takže je potřeba tu službu opravit, aby nepoškozovala data ale používala žurnál a kontrolní součty.
Ještě vám chybí protipříklad pro službu, která žádná data na disk nezapisuje. Předpokládám tedy, že tušíte, že tvrzení „existuje služba, kterou je nejlepší po pádu hned znova nastartovat“ nelze vyvrátit tvrzením „existuje služba, kterou po pádu nelze hned znova nastartovat“.