Ubuntu přejde z upstart na systemd (diskuse)

[backinabag]

Konecne.

[alfonz mucha]

no... zas takovou dobrou náladu bych z toho neměl, vypadá to na první pohled dobře, ale myslím že bude potřeba tak hodně práce, aby se převedli všechny ty skripty a zkontrolovala funkčnost aspoň většiny balíků.

[alfonz mucha]

aby vývojáři převedli skripty..

[potato]

To bych neviděl jako takový problém. Jednak se Ubuntu přidává dost pozdě, takže se systemd už je spousta zkušeností (jakéhokoli druhu). Druhak stejně hlavně přebaluje Debian, takže to za něj převážně vyřeší vývojáři Debianu.

[sid]

Ludia co hlasovali za upstart a jeho buducnost sa musia citit ako blbci. Pragmaticke riesenie ale mozno by cela debata prebehla inac keby canonical naznacil, ze on sa zmene nebrani.

[PavelC]

Co bude s Chrome OS od Google ? Zustanou u upstartu nebo prevezmou vyvoj ?

Jinak dost zklamani jak vymekli, konkurence a alternativa k systemd by se hodila. No ale asi se to dalo cekat od prebalovacu Debianu Testing.

[tust]

Komu by prospelo udrzovat upstart?! Jen zbytecne tristeni sil. Linux potrebuje konsolidaci.

[pavlix]

A především komoditizaci, že.

[Josef Kufner]

Tak, tak. Jestli to nakonec bude to či ono, je celkem jedno. Podstatné je, aby to byla jedna věc a vývoj se soustředil na jeden nástroj.

Nakonec by ale asi bylo nejlepší vzít z obou initů to dobré a dát to dohromady.

[potato]

Lennart už vyvíjí systemd dost dlouho na to, aby ho opustil a vrhl se předělávat něco jiného. To dává naději, že rozumné připomínky nakonec budou nějak zapracovány -- a pro luddity je tu stále Slackware...

[pavlix]

Lennart už vyvíjí systemd dost dlouho na to, aby ho opustil a vrhl se předělávat něco jiného.

Lennart se vyvíjí, nepracuje pořád stejně. Dosud byly jeho výtvory relativně jasně ohraničené a tak na nich bylo jasně vidět, zda jsou aktivní nebo opuštěné. Jenže systemd je balík, jehož účelem je sloučit všechny možné projekty do jednoho. Nelze tedy očekávat, že by systemd jako celek úplně opustil. Prostě kdykoliv dostane nový nápad, udělá si na něj v systemd nový podadresář, to je všechno.

Z hlediska počtu commitů je už teď zřejmé, že projekt jako celek tahnou jiní a dneska už obsahuje i části, kterým Lennart třeba ani nerozumí. Ale hlavně, že všichni budou navždy věřit, že to je jeho projekt. Zároveň tím skvěle vyřešil výtku, že své projekty opouští, protože postupem času bude mít jen jeden aktivní projekt, do kterého si může přidat cokoliv.

[potato]

Jenže systemd je balík, jehož účelem je sloučit všechny možné projekty do jednoho

Až se v něm objeví Sage, TeXlive a Battle for Wesnoth, tak se fakt začnu bát...

Ale vážně. Za co se nám dlouhé roky vysmívali bsdčkaři? Že Linux není žádný operační systém, nýbrž jen jádro + chaotická sbírka dalších komponent.

LSB ze začátku vypadalo, že by mohlo v tomto směru trochu pomoci, ale pak v něm definivitně převážily committee typy a začalo ‚standardizovat‘ neexistující adresáře, rpm, Gtk+, etc. [*]

Systemd je asi první[**] relevantní pokus o konsolidaci do skutečného operačního systému. Ten by samozřejmě ve výsledku musel zahrnovat i věci jako libc nebo dynamický linker, ale nebudu Lennartovi raději dodávat nápady...

[*] Nejsem hater, rpm i Gtk+ mám rád a používám.

[**] V oblasti uživatelských/serverových OS. Specializované systémy nepočítám.

[pavlix]

Až se v něm objeví Sage, TeXlive a Battle for Wesnoth, tak se fakt začnu bát...

Tak zatím se tam sbírají věci z lennartovských a spřátelených projektů jako je udev, dbus, asyncns, consolekit a mnoho dalších. Jestli jde mezi spřátelené projekty řadit Lennartův oblíbený Connman, tak přidej DHCP klient a časem server. Předpokládám, že takové základní věci jak HTTP klient/server už tam jsou.

Ale vážně. Za co se nám dlouhé roky vysmívali bsdčkaři?

Na embedded jsme měli busybox, na velké systémy teď máme systemd. Časem budeš mimo systemd potřebovat jen velmi málo softwarových balíků k tomu, aby jsi nabootoval základní operační systém. Je docela možné, že se inspirují u RMS a budou požadovat po distribucích, aby namísto linux vždy uváděly systemd/linux.

Systemd je asi první[**] relevantní pokus o konsolidaci do skutečného operačního systému.

Dá se tedy říct, že rozšíření systemd do hlavních distribucí znamená zánik linuxových systémů, jak je známe a budeme mít na stole BSD-style distribuce, jen s jiným jádrem a userspace? Kromě BSD takto funguje i Apple a dá se říct, že ji Microsoft, až na to, že nedrží základní systém jako open source.

[potato]

V podstatě souhlas. Neříkám, že je to to, co jsme si vždycky přáli k vánocům -- ani, že je to tragédie. Ale celkově bych tomu dal šanci, protože idea Linuxu ve smyslu širšího systému než jádro není v principu špatná. Otázka je realizace a jaká omezení to přináší pro použití, která si tvůrci systemd neuměli představit.

Každopádně linuxový ‚ekosystém‘ je docela odolný a vždy v něm existují alternativy. Kdyby se to celé mělo ukázat jako slepá ulička, tak zavržení a náhrada systemd je otázka 3 let v uživatelských distribucích, serverové budou muset chybná rozhodnutí snášet 6-10+ let, ale to je tak se vším... (Většina diskutujících zde si tohle stejně nedovede představit -- a popravdě ani já; RHEL 5 extended support v roce 2022 je prostě něco mimo běžnou zkušenost.)

[JS1]

Ale celkově bych tomu dal šanci, protože idea Linuxu ve smyslu širšího systému než jádro není v principu špatná.

Jelikoz profesionalne delam mainframe, kde to v podstate tak je (i kdyz mainframe je z hlediska vyvoje OS totalni Australie), myslim si to taky, ze to Linux potrebuje.

O systemd prakticky nic nevim (pouzivam temer vyhradne Ubuntu, i kdyz uvazuji o prechodu na Debian), ale neco jsem o tom cetl od te posledni debaty, a prijde mi, ze vetsina skutecne technickych diskusi se kloni k tomu, ze je to vynikajici volba.

[Pavel]

Nesrovnavej picovinu systemd s BSD, to je dost rozdil (ne, opravdu to neni jenom o tom, ze "je to ve stejnym git repozitari") . Systemd je prilis monoliticky.

[potato]

Systemd stále není dost monolitcký ;)

[JS1]

"Prilis monoliticky" neni technicka, ale politicka namitka. Jadro je take monoliticke. Ale kdyz se podivas podrobneji, zjistis, ze ani u jedne z tech veci to neni tak uplne pravda, a ze je to proste urcite inzenyrske rozhodnuti (kompromis), a naprosto v poradku.

[Pavel]

Ano, je to politicka namitka (postavena na technicke vlastnosti/nedokonalosti systemd). A proc by nemela?

[kavol]

"Prilis monoliticky" neni technicka, ale politicka namitka. Jadro je take monoliticke.

o kousek výše jsem nechápal, jak to myslíš s tou "většinou skutečně technických diskusí" ... teď je to jasné, co se ti nelíbí, je politika, co se ti líbí, je technické, že?

monolitičnost jádra se absolutně nedá srovnávat se systemd - jádro mi například nenutí žádný ovladač na grafiku, můžu si vybrat, jestli budu používat nouveau nebo bastl od nVidia; v podání systemd by to bylo, že jádro pohltí nouveau, nepůjde to vypnout (čili na strojích s jinou grafikou budu mít kus kódu absolutně k ničemu), a kdybych náhodou chtěl používat bastl od nVidia, tak ho to stejně nenechá šáhnout na grafiku přímo a všechno bude muset procházet přes to nouveau, které na tom hardwaru sedí jak žába na prameni

[JS1]

Ne, myslim to tak, ze (a odpovidam i Pavlovi) clanky na toto tema, co jsem cetl, pokud byly vecne a technicke, systemd prijimaly, pokud byly spis vagni a politicke (treba kontroverznost Lennarta, je to zmena, atd.), systemd odmitaly.

Takze muj (laicky) obrazek z toho je, ze systemd je technicky lepsi reseni, protoze neexistuji dobre (technicke) protiargumenty.

Jinak si myslim, ze pokud bude opravdu problem v neexistenci alternativ, tak ty casem vzniknou, ale budou se systemd dost kompatibilni. Jen to chce ten cas.

[pavlix]

Mně to celé přijde jako takový sociologický pohled a já jsem spíš na ten technický pohled a ty reálné technické argumenty. Ani velké množství debilních kritik systemd mě nepřesvědčilo tento pohled změnit ;).

[JS1]

I ty technicke argumenty pro samozrejme davaji smysl, ale tam je tezsi to hodnotit, kdyz druha strana zadne nedava.

[pavlix]

Žádná druhá strana neexistuje, svět není černobílý.

[Pavel]

Tyjo, me prijde ze pro-systemd strana nedava zadny technicky argumenty. Furt je to jenom "novy, inovativni, novy vlastnosti, sysvinit je stary...". Jestli to nebude tim, ze oba tu druhou stranu ignorujeme? Ale ja mam vyhodu ze si to uvedomuju a nedelam z toho "svatou pravdu".

[pavlix]

A oni mají tu výhodu, že se prosadili a tvůj názor je jim u prdele :).

[Pavel]

Tak to delaji chybu. Za chvili se systemd a Linuxem obecne zacnou zajimat mainstreamovy media v souvislosti s... to je tajemstvi

[JS1]

Tyjo, me prijde ze pro-systemd strana nedava zadny technicky argumenty.

Me treba tohle prijde dost technicke. Videl jsem i dalsi, ale uz na ne nemam po ruce odkazy.

[Pavel]

Politicky kecy. Promin, ale stale nic rozumnyho.

[martin]

https://lists.debian.org/debian-ctte/2013/12/msg00234.html

[JS1]

Diky, to je presne priklad ciste technicke argumentace ve prospech systemd.

[kavol]

myslíš třeba jak se tam technicky vypořádává s ostatníma alternativama?

[JS1]

Nevim, co mas na mysli - takhle nekonkretne ta diskuse nema smysl.

Ale kdyz vezmu treba Upstart, o kterem pise jako o alternative, tak tam duvody uvadi. A i puvodni autor Upstartu sam priznal, ze systemd je technicky lepsi alternativa.

Rikam, pokud ma nekdo pocit, ze jeho alternativa je technicky lepsi reseni, at to sepise, v cem a proc. Ale zatim jsem takovy clanek necetl.

[kavol]

konkrétně se tomu věnuje nejprve v této větě: "Many replacements have been suggested, only one of them really took off"

potom říká: "There are other init systems besides sysvinit, Upstart and launchd. Most of them offer little substantial more than Upstart or sysvinit. The most interesting other contender is Solaris SMF, which supports proper dependencies between services. However, in many ways it is overly complex and, let's say, a bit academic with its excessive use of XML and new terminology for known things. It is also closely bound to Solaris specific features such as the contract system."

no a pak je tam ještě dvě položky ve FAQ:

"launchd is a great invention, but I am not convinced that it would fit well into Linux, nor that it is suitable for a system like Linux with its immense scalability and flexibility to numerous purposes and uses."

"Well, before we started this we actually had a very close look at the various systems, and none of them did what we had in mind for systemd (with the exception of launchd, of course). If you cannot see that, then please read again what I wrote above."

co z toho považuješ za "technický argument"?

[JS1]

Jsou tam i jine argumenty a vetsina z nich je technicka. U toho, co konkretne zminujes predpokladam, ze ten argument ma, ale nechce se s nim rozepisovat. Nemam duvod neverit, ze se skutecne na jine systemy nedival. Pokud myslis, ze se myli, v cem? V cem launchd nebo SMF resi problemy, ktere se snazi resit systemd, lepe nez systemd?

[Pavel]

Ale zatim jsem takovy clanek necetl.

Meh. Samozrejme ze jsi takovy clanek necet a ani kdyby kdokoliv nejaky postnul tak si ho neprectes, prece si nebudes kazit svuj svetonazor.

[kavol]

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[JS1]

chtělo by to aspoň nějaký příklad takového článku, aby si ostatní mohli učinit obrázek, co kolegovi nepřijde dostatečně technické

Kdyz jsem hledal odkaz na "Rethinking PID 1", narazil jsem na takovy (primo jako kritiku toho clanku). Bohuzel Google se u me doma chova jinak nez v praci, takze po ruce nemam odkaz. V podstate jediny jeho argument ale byl - staci mi sysvinit. No, tak to je treba trosku malo.

jak reagoval na výtku o monolitičnosti, a moje dovysvětlení, že to s jádrem fakt nelze srovnávat, jen tiše ignoroval

Protoze jde o nepochopeni. Linuxu bylo nadavano do monoliticnosti uplne stejne, jako se dnes nadava na systemd, ale pritom nebyla zadna lepsi hotova alternativu. Proste, duraz na "modularitu" je hezky teoreticky koncept, ale ma i sve prakticke nevyhody.

Krome toho si myslim, ze alternativy k systemd casem vzniknou.

[JS1]

Samozrejme ze jsi takovy clanek necet a ani kdyby kdokoliv nejaky postnul tak si ho neprectes, prece si nebudes kazit svuj svetonazor.

Necetl, protoze jsem na takovy nenarazil. Delal jsem si jen maly pruzkum, systemd nepouzivam. Tohle jsou takove kecy - pokud mas pocit, ze takovy clanek existuje (ktery kritizuje systemd z inzenyrskeho hlediska), muzes na nej odkazat tady a ted. A ja si ho prectu.

[JS1]

Až se v něm objeví Sage, TeXlive a Battle for Wesnoth, tak se fakt začnu bát...

Ale nebylo by to hezky? System, ktery by nabootoval do Battle for Wesnoth s PID 1..

[Drom]

...za půl vteřiny...

[Josef Kufner]

To jako že se po 15 letech vývoje dostaneme na úroveň DOSu, kde v config.sys bylo menu, který init chci zavést?

[Love_Dali]

Asi nejdu dost do hloubky, ale z pozice víceméně uživatele jsem nikdy neměl žádný problém se Systemd. Spokojeně jsem to používal na Archu a bylo to jednoduché a přehledné na spravování a fungovalo, takže proč ne? Prosím bez flamu ;) Mimochodem, pochopil jsem dobře, že Ubuntu 14.04 nebude defaultně (tzn ve stavu po vydání) mít v sobě mir? Zkoušel jsem včera daily build a připadám si, že jsem se zase vrátil v čase Intel a 555m a opět black screen ;)

[trekker.dk]

takže proč ne

Protože systemd rozbíjí věci, když Lennart prohlásí, že takhle je xyz správně a jinak to dělat nejde. Kdyby ta věc byla jenom init systém s volitelnou možností, že to bude dělat i supervizor, stejně jako s volitelnou možností zapnout další věci, které jsou v tom povinné a natvrdo zapnuté, neměl bych s tím problém.

[martin]

jjjjj, arch se uz od prechodu rozbil nejmin 20x !

(no)

[AsciiWolf]

No, tak zrovna v případě Archu to není nic překvapivého.

[martin]

sarcasm alert! (vzdycky na nej zapomenu)

[pta]

Pro vas to je cerna skrinka, ktera nejak funguje. Ale pro adminy co se musi ucit uplne jiny system zavadece, nastroju pro spravu, format konfiguracnich souboru to je megaopruz a komplikace, kterou jim tezko nekdo muze vysvetlit, kdyz jim dosavadni init a rc skripty fungovaly a maji dost svych starosti. Navic ta konfigurace ma omezenou sadu pravidel a nektere specificke upravy site na miru zakaznika z tech flexibilnich shell scriptu proste prepsat nejdou a budou se to muset nejak obchazet (hint ExecStatus).

Zrovna na ArchLinuxu jsem se se systemd seznamoval a okusil jsem bezmoc pri patrani po chybe v binarce oproti shell scriptu. Nefungovalo nastaveni pro consoli a po pul dni googlenim, laborovanim se strace jsem se na to vykaslal. Mam jenom jedny nervy.

[teplos]

Ono na druhu stranu to nie je ziadny rocket sciene tie upstart scripty. Vela inej prace maju aj ostatny a nevyplakavuju nad kazdou zmenou.

P.S to ste si naozaj myslel ze budete pouzivat doterajsi init system az do dochodku sa ten system nezmeni?

[kverulant]

Já třeba chápu, že uživatelům se změny nelíbí. Ale z hlediska programátora jsou ty změny někdy nutné. Není možné si myslet, že program vytvořený před 20 lety bude splňovat dnešní požadavky. Je potom na zvážení jestli začít znovu nebo se snažit vršit hack na hack aby to nějak fungovalo.

[Hans1024]

Vrsit hack na hack!

[j]

Program napsany pred 20ti lety splnuje soucasne pozadavky naprosto dokonale, protoze za tech 20 let byl dokonale odladen. "tentyz" napsany dnes bude 1000x vetsi, milionkrat pomalejsi, a bude mit N+oo chyb.

Navic (stejne jako systemd) tvurce rozkaze, ze trebas z gcc je treba vyhodil 1/2 funcnosti, protoze se to politicky nehodi prave k tomuhle SW. A lidi kteri by chteli gcc pouziva bez tohodle shitu maji smulu, protoze jim prestane fungova.

Viz udev a eth like ... a samo se najdou i dalsi. Fakt uzasny vyhodit funci, ktera je v tom 10+let ... a lidem to oznamit po distribuci novy verze ... az kdyz jim systemy nenabootujou.

[JS1]

Program napsany pred 20ti lety splnuje soucasne pozadavky naprosto dokonale, protoze za tech 20 let byl dokonale odladen.

Pokud treba Red Hat 4 splnuje tve pozadavky "dokonale", proc ho nepouzivat? Bohuzel to ale takto jednoduche neni.

[Roslav]

Program napsany pred 20ti lety splnuje soucasne pozadavky naprosto dokonale, protoze za tech 20 let byl dokonale odladen. "tentyz" napsany dnes bude 1000x vetsi, milionkrat pomalejsi, a bude mit N+oo chyb.

Ako napriklad X11 a Wayland.

[Foo Bar]

Meh, jasně. Programování jako obor se za posledních dvacet let vůbec nevyvíjí, a když už tak jen k horšímu. Doporučuji nahodit Bind 4... protože ten musí být jó teda odladěný.

[Milan Jurik]

Myslím, že jsi přesně nevstřebal, co pan 'j' chtěl říci. Bind 4 je jen verze Bindu, dnes v poslední verzi odladěného programu, i když je fakt, že ve verzi 9 došlo k velkým změnám, v podstatě k úplnému přepisu. Ale podle principů původního systému. A teď si vem Bind 10, což je vlastně jiný program pod stejným jménem... Skoro bych řekl, že geneze Bindu naopak potvrdí tezi pana 'j'.

[Foo Bar]

Bind 8 byl úplný přepis, Bind 9 taky a Bind 10 taky. Ale rozhodně to nebylo tím, že by Bind 4 byl "odladěný"... Bind 10 taky nevzniká, protože by byl Bind 9 odladěný, ale protože už je tak dolepený, že už se to dál nedá.

[little.owl]

Tak tohle me take schodilo ze zidle ....

Ta bariera mezi nekterymi adminy a programatory je neuveritelna.

[Honza Jaroš]

Ta bariera mezi nekterymi adminy a programatory je neuveritelna.

Něco k tématu...

[little.owl]

No, S-class si tedy kvuli tomu kupovat nebudu ....

[Honza Jaroš]

Bonmot hezký, ale o pochopení nesvědčí...

[little.owl]

Hmm.?

[Honza Jaroš]

No vždyť říkám.

Já vím, co je S-class.

[little.owl]

Pak se ptam jaky bonmot mate na mysli.

[Honza Jaroš]

No, S-class si tedy kvuli tomu kupovat nebudu....

Pokud tohle nebyl bonmot, tak se nám to nějak zamotává...

[little.owl]

Nebyl.

[Honza Jaroš]

Dobrá. Prostě jenom pochopit, že ten blbej nemusí být jen admin - na což bohužel spousta vývojářů přijde až poté, co jsou donuceni svůj výtvor začít používat. O tom je ten článek. Kupovat si Mercedesa vás určitě nenutím (a vím, že děláte v tomhle oboru)...

[little.owl]

Jenze o tom anglicke rceni "eating your own dog food" neni, ostatne ani clanek. Prenesene to znamena "[po]uzivej sam to na cem delas, nebot tim ukazujes duveru v to, co delas".

Do adminu se nenavazim, pouze jsem konstatoval, ze ta bariera mezi nimi a programatory je nekdy obrovska, a chyba nejspise na obou stranach.

[gsnak]

Vymenim tvoj black screen za moju 2 FPS slideshow na plousbo.

[mir]

Očekávám, že nebude dlouho trvat a po podobném oznámení se ubuntu rozloučí s Mirem.

[kralyk z abclinuxu]

V tom případě bychom se třeba konečně mohli dočkat širšího nasazení Waylandu...

[Bedňa]

[Ján Dráb]

S Mirom sa nerozlucia, potrebuju ho pre ubuntu touch.

[R]

A kto potrebuje Ubuntu Touch?

[Conscript89]

A kdo kdy neco takovyho videl?

[Příchozí]

a co to je vlastně Ubuntu touch? (sarcasm)

[Pavel]

RIP Ubuntu

[mankind_boost]

Čert vem Ubuntu, ale Debian se zbláznil!

[...]

ale to je tomu uz nekolik let co se tak satlo.

[marbu]

Zajimavá je taky reakce původního autora upstartu.

[koroptev]

co presne bylo spatne na sysv initu? na serveru/desktopu se 100% funkcnim uspavanim?

[Bedňa]

Všetko čo bolo po teraz v Linux enviroment bolo zlé. Sa teším na dobu keď už bude všetko dobré. Za tie roky spokojného užívania si Linuxu sa konečne pohneme do fázy Win95 a blue screen. Už tie tupé hlášky s nemenovaných distribúcií "stalo sa niečo zlé" sú veľa hovoriace kde sa budeme uberať.

[potato]

Nevím, kolik jsi napsal nebo udržoval SysV init skriptů, ale neznám nikoho, kdo by to dělal rád. Jsem rád, že jsme se té věci zbavili. Jak moc jsme si pomohli, to ukáže čas.

[Heron]

Já jsem jich pár napsal a nevidím na tom nic až tak šíleného. Vždyť je to v postatě skript, kterému se předají parametry jako start a stop. Nic víc. Co je na tom proboha tak těžkého, že je nutné k vůli tomu rozbít a zcela překopat pid1?

Navíc většina serverů (ve smyslu software) podporuje své spouštění přímo z řádky jako služba -d nebo službad apod. Jak si je budete spouštět při startu vámi spravovaného OS je zcela na vás. Já nevím, jestli je to pro některé novinka, ale ano, Linuxový OS si můžete klidně úspěšně nabootovat s init=/bin/bash.

[volic_plukovnik]

Treba to ze se musi na urovni procesu resit SEGV a jine duvody padu procesu, kdezto systemd tohle umi hlidat.

[Heron]

Nemusí.

[potato]

Na klasickém SysV initu v době jeho vzniku, kdy měl umět spustit a ukončit nějaké jednoduché věci při nějakých runlevelech, asi nic. Pokud ale chceš ty věci restartovat a reloadovat, zjišťovat jejich stav, definovat mezi nimi závislosti namísto explicitního pořadí, ukončovat včetně potomků, řešit inteligentně selhání, spouštět pod jinými uživateli a skupinami, mít standardní interface k tomu, kdy jsou zapnuté a vypnuté, aktivovat on-demand, ..., tak se vršil hack na hack a bastlily se komplikovanosti v shellu. Viz prakticky jakýkoli SysV init skript v současných distrech (resp. v nedávné minulosti, kdy se ještě SysV hojně používal), který navíc z vyjmenovaného řeší tak půlku.

[Bedňa]

Rejče a teraz nejaký konkrétny príklad koho toto trápi na desktope?

[AsciiWolf]

Například vývojáře či package maintainery?

[Bedňa]

Ty to majú po rokoch už vychytané. Mne všetko funguje, keď chcem niečo viac napíšem si skript.

[Foo Bar]

Jsem rád, že to za mne tak dobře víte, že to mám po letech už vychytané, a nepije mi to krev pokaždé, když do toho musím šáhnout. Díky za objasnění, že jsem se vlastně mýlil.

[Bedňa]

Nieje zač a rád by som tie hrôzostrašné skripty videl, zatiaľ som o nich len počul.

[Foo Bar]

Ptal jste se koho to trápí, dostal jste odpověď, že mimo jiné maintainery, a to jste smetl ze stolu, že je to vlastně vůbec netrápí. Doporučuji se příště zeptat těch *maintainerů*, než za ně příště budete mluvit.

Já Vám žádné hrůzostrašné skripty ukazovat nemusím. Já je jen nechci do nekonečna dál udržovat.

[Bedňa]

Já je jen nechci do nekonečna dál udržovat.

Ja zas nechcem zbytočné závislosti v Gnome, ovšem pokiaľ je vývojár na prvom mieste, tak sa ako užívateľ ospravedlňujem.

[Foo Bar]

Věnoval jsem balíčkování dost svého volného času. Pokud to chcete jinak, budete muset přiložit sám ruku k dílu. Alespoň co se týče Debianu, o kterém to tady tak nějak je...

[Bedňa]

Věnoval jsem balíčkování dost svého volného času.

Zato moc dík. Mám na veci čo sa momentálne dejú v Linux enviroment dosť kritický pohľad. Rozhodne je to o tom, namiesto doplnenia funkcionality napríklad toho čo teba páli všetko zahodíme a napíšeme to nanovo, popritom nasereme dlhoročných užívateľov Linuxu a ešte im zoberieme nejakú tú funkcionalitu.

[j]

Cimz se jasne predvedlo, jak uzasny a mocny nastroj to je. Sem zvedav, jak budes hackovat binarku, az narazis na to, ze tvurce jaksi nepocital se situaci X, pripadne Y ... nebo Z. Budes vprdeli jak bata s drevakama.

[Heron]

+1

[Josef Kufner]

To záleží na tom, jak dobře je ta binárka udělaná a jak počítá s budoucí rozšiřitelností (na úrovni konfigurace, bez kompilování).

[kralyk z abclinuxu]

Cimz se jasne predvedlo, jak uzasny a mocny nastroj to je.

Sem zvedav, jak budes hackovat binarku, az narazis na to, ze tvurce jaksi nepocital se situaci X, pripadne Y ... nebo Z. Budes vprdeli jak bata s drevakama.

Zajímavý je, že v každé jiné části systému tohle absolutně není problém a nikdo neřekne proti binárkám ani popel.

Nicméně když už by musel být init naskriptován, bylo by mnohem lepší, kdyby byl naskriptován v nějakém skutečném general purpose skriptovacím jazyce (např. python).

[pavlix]

Zajímavý je, že v každé jiné části systému tohle absolutně není problém a nikdo neřekne proti binárkám ani popel.

V každé jiné části systému lze binárka triviálně nahradit za jinou binárku, haldu skriptů nebo cokoliv. To bude nejspíš důvod, proč to jinde není problém. Dokonce i takový Gnome Shell se dá do velké míry poladit bez rekompilace pomocí rozšíření.

Nicméně když už by musel být init naskriptován, bylo by mnohem lepší, kdyby byl naskriptován v nějakém skutečném general purpose skriptovacím jazyce (např. python).

Já jsem měl jako init vždy binárku, co si pamatuju:

# file /sbin/init
/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped

Momentálně mám dokonce binární i správce služeb nad ním, což má spoustu výhod:

# file /sbin/rc
/sbin/rc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped

Takže v shellu mám až ty initskripty samotné, vyberu jednoduchou službu:

#!/sbin/runscript

depend() {
        use net
        need dbus
        before nfs
        after logger
}

start() {
        ebegin "Starting cupsd"

        checkpath -q -d -m 0775 -o root:lp /var/cache/cups
        checkpath -q -d -m 0775 -o root:lp /var/cache/cups/rss
        checkpath -q -d -m 0755 -o root:lp /run/cups
        checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs

        start-stop-daemon --start --quiet --exec /usr/sbin/cupsd
        eend $?
}

stop() {
        ebegin "Stopping cupsd"
        start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd
        eend $?
}

Pokud nepočítám prázdné řádky a řádky kvůli hezkému formátování, tak nejvíc řádků zabírají nějaké checky, které tam nejspíš nemají, co dělat. Hlášky by se daly řešit o vrstvu výše. Teoreticky by se daly zavést nějaké proměnné stylu systemd a tím celý start/stop zautomatizovat a vyhodit.

Můžeme se bavit o tom, zda to má systemd vyřešení lépe nebo hůře. Můžeme se bavit o tom, co by se dalo dělat s delšími a komplikovanějšími skripty. Lze zavést i sociologickou debatu o tom, jestli limitace systemd jdou považovat za výhodu, protože donutí upstream i maintainery dělat věci jen s primitivními prostředky, které jsou k dispozici. Ale lhát si do kapsy, že bez systemd je potřeba vytvářet 150řádkové initskripty, to mě nebaví.

[kralyk z abclinuxu]

V každé jiné části systému lze binárka triviálně nahradit za jinou binárku, haldu skriptů nebo cokoliv. To bude nejspíš důvod, proč to jinde není problém. Dokonce i takový Gnome Shell se dá do velké míry poladit bez rekompilace pomocí rozšíření.

Nevidím rozdíl oproti systemd nebo initu obecně.

Já jsem měl jako init vždy binárku, co si pamatuju

Prosil bych netahat za slova.

Momentálně mám dokonce binární i správce služeb nad ním, což má spoustu výhod

V tom případě bych měl citovat předřečníka: "Sem zvedav, jak budes hackovat binarku, az narazis na to, ze tvurce jaksi nepocital se situaci X, pripadne Y ... nebo Z. Budes vprdeli jak bata s drevakama."

Jinými slovy takhle kritika se dá aplikovat na jakoukoli binárku, protože žádná binárka nikdy nepokreje 100% možných situací.

Takže v shellu mám až ty initskripty samotné, vyberu jednoduchou službu:

Kdybych já chtěl ladit tenhle skript, jakožto člověk neznalý příslušného init systému (je to Debian?), musel bych nastudovat všechny ty příkazy a funkce (už ta první část - řešení dependencí v bashi - mě na první pohled dost děsí).

Fór je v tom, že lidi, kteří s tímhle systémem pracují často, ho dobře znají, a tudíž jim přijde mnohem "flexibilnější" a "snažší na pochopení" než systemd.

[pavlix]

Nevidím rozdíl oproti systemd nebo initu obecně.

Pokud nevidíš rozdíl mezi rozšiřitelným a nerozšiřitelným software, tak asi vyhledej pomoc jinde než u mě.

Prosil bych netahat za slova.

Tahám jen za ta, která považuju za podstatná.

Kdybych já chtěl ladit tenhle skript, jakožto člověk neznalý příslušného init systému (je to Debian?), musel bych nastudovat všechny ty příkazy a funkce (už ta první část - řešení dependencí v bashi - mě na první pohled dost děsí).

Tak se do něj podívej ještě jednou, je vcelku triviálně srozumitelný. Ten zápis závislostí je navenek deklarativní a systemd to řeší podobně.

Fór je v tom, že lidi, kteří s tímhle systémem pracují často, ho dobře znají, a tudíž jim přijde mnohem "flexibilnější" a "snažší na pochopení" než systemd.

Pak ale nevím, proč to píšeš mně, který balím věci pro fedoru, tedy pro systemd, a Gentoo initscript jsem neviděl několik let a tenhle jsem otevřel kvůli tobě. To jsou zas nějaké pochybné sociologické průzkumy, ne?

[kralyk z abclinuxu]

Pokud nevidíš rozdíl mezi rozšiřitelným a nerozšiřitelným software, tak asi vyhledej pomoc jinde než u mě.

Systemd mi nepřipadá nerozšiřitelný - koneckonců se dá afaik navázat i na ty bash skripty. (Krom toho ne každý sw na linux desktopu je (snadno) rozšiřitelný, že...)

Pak ale nevím, proč to píšeš mně, který balím věci pro fedoru, tedy pro systemd, a Gentoo initscript jsem neviděl několik let a tenhle jsem otevřel kvůli tobě. To jsou zas nějaké pochybné sociologické průzkumy, ne?

Ne, to bylo spíš v kontextu vlákna...

[pavlix]

Systemd mi nepřipadá nerozšiřitelný - koneckonců se dá afaik navázat i na ty bash skripty.

Navázat na bash skripty se dá relativně omezenými způsoby. Ne nadarmo jeden z těch způsobů (podporu legacy initscripts) v Gentoo vypínají, protože s jejich skripty to stejně nefunguje. Druhý způsob mi vcelku vyhovuje a totiž používání samostatných skriptů a jejich referencování přímo z .service souborů.

Jenže jedna věc je, co mně osobně vyhovuje a nevyhovuje, druhá je, že čtu v diskuzích dětinské argumenty typu: Ale ty jsi mi taky jednou rozbil bábovičku. Zajímavý je, že v každé jiné části systému tohle absolutně není problém a nikdo neřekne proti binárkám ani popel.

Krom toho ne každý sw na linux desktopu je (snadno) rozšiřitelný, že...

Přínos či význam této glosy je prosím jaký?

[kralyk z abclinuxu]

co presne bylo spatne na sysv initu? na serveru/desktopu se 100% funkcnim uspavanim?

Náročná údržba, implementace typu "udělej si sám v bashi".

Ale mělo to i pozitiva - např. jsem si mohl během bootování PC jít v klidu udělat čaj a přečíst noviny.

[Josef Kufner]

Zkus si vyrobit jednoduchého démona, který bude například pípat. K němu si zkus vyrobit SysV init script, který to spustí, a pak zkus nakonfigurovat systemd, supervisord, nebo cokoliv podobného, aby to udělalo totéž.

Na to první potřebuješ cca 150řádkový init script a ještě jednou tolik na správnou démonizaci procesu.

S rozumným supervisorem stačí pár řádek konfiguračního souboru bez démonizace. A jako bonus to umí démona restartovat, když upadne.

[pavlix]

Na to první potřebuješ cca 150řádkový init script a ještě jednou tolik na správnou démonizaci procesu.

Zajímavé, že na Gentoo jsem viděl initscripty velmi krátké a jednoduché. Tím neříkám, že se mi myšlenka supervizoru nějak příčí, právě naopak. Ale ten argument mi přijde pitomý, když jediný důvod, proč měly některé initscripty 150 řádků byl ten, že to tak maintaineři dotyčných distribucí chtěli.

[kavol]

+1, přijde mi dosti zoufalé, když příznivci systemd nemají nic jiného než takto vylhané argumenty

(btw, na výše uvedené by tuším stačil jeden řádek v inittab )

[Michal Vyskočil]

(btw, na výše uvedené by tuším stačil jeden řádek v inittab )

Vážně? Jak v tom inittabu napíšeš, aby se beepd spouštěl až po inicializaci zvukovky? Nebo jak tam vložíš definici bez toho, aby se služba v daném runlevelu automaticky spustila? Většina lidí ani netuší, čeho všeho je /sbin/init vlastně schopný, protože chybějící vlastnosti se "vyřešily" jeho nepoužíváním .

[kavol]

to nebylo v zadání :-p

[dustin]

Hm, takže bylo zadání nekompletní. V praxi to však potřeba je.

[kavol]

to je možné, nicméně tady se nebavíme o praxi ale o tom, že kolega výše napsal totální blábol

[Heron]

A taky je v praxi potřeba zajistit, aby se zesílil zvuk, pokud byl předtím ztlumený (to v zadání taky nebylo, ale očekává se, že to pípání bude slyšet), a aby byl přehrán na zvukovce v dosahu uživatele. A samozřejmně se očekává, že to pípání poběží pořád, takže init systém musí umět reagovat na pád beepd. Ano, přesně takto vznikají věci jako systemd a pa.

[dustin]

A taky je v praxi potřeba zajistit, aby se zesílil zvuk, pokud byl předtím ztlumený (to v zadání taky nebylo, ale očekává se, že to pípání bude slyšet), a aby byl přehrán na zvukovce v dosahu uživatele. A samozřejmně se očekává, že to pípání poběží pořád, takže init systém musí umět reagovat na pád beepd.

Jistě, s tím musí vývojář dopředu počítat, od toho je to profík se zkušenostmi a předvídavostí a ne robot přepisující jen písmenka zadání do kódu.

[Michal Vyskočil]

to nebylo v zadání :-p

Zásah, potopená

[Honza Jaroš]

On už neexistuje PC Speaker? Pokud si pamatuju, na pípání stačilo zavést modul pcspkr i na počítačích bez zvukové karty. Možná je to už teď jinak, na notebooku nemám tenhle modul zkompilovaný a jinde mám jen stará jádra z CentoOS nebo Debianu Squeeze, kde tenhle modul ještě je...

[Michal Vyskočil]

jediný důvod, proč měly některé initscripty 150 řádků byl ten, že to tak maintaineři dotyčných distribucí chtěli.

Musím se za všechny distribuční maintainery ozvat - init skripty jsou u většiny distribucí dané především její policy. Typicky se nový skript začíná tvořit zkopírováním nějakého obecného skeletonu a jeho úpravami.

[pavlix]

init skripty jsou u většiny distribucí dané především její policy.

Jasně. A ta policy se asi napsala sama. A jediný způsob, jak tu policy změnit je systemd. A to tu někde JS psal, že technické argumenty jsou na straně systemd a politické argumenty na druhé straně (bez bližší specifikace).

[Michal Vyskočil]

Jasně. A ta policy se asi napsala sama. A jediný způsob, jak tu policy změnit je systemd. A to tu někde JS psal, že technické argumenty jsou na straně systemd a politické argumenty na druhé straně (bez bližší specifikace).

Já o systemd ve svém příspevku nenapsal ani slovo, takže těžko přetěžko reagovat na někoho, kdo vidí Lennarta i tam, kde není ...

[pavlix]

Budu ošklivý a znovu se zeptám na tu část příspěvku, kterou ignoruješ. Ta distribuční politika, která podle tebe vyžaduje 150řádkové skripty, se napsala sama, aby mohla trápit chudáky správce distribucí?

[Michal Vyskočil]

Ne, tu přece napsal Lennart, aby se za pár let mohl vytasit se systemd ... ale o tom můj příspěvěk vážně nebyl. Mě šlo o to popsat, jaký byl obecný postup pro psaní init skriptů a zdůraznit fakt, že těch hypotetických 150 řádek vesměs nepadá na hlavu nebohých maintainerů, jak by se mohlo zdát z tvého příspevku. Howgh, domluvil jsem!

[pavlix]

Nemám dalších otázek.

[kralyk z abclinuxu]

Typicky se nový skript začíná tvořit zkopírováním nějakého obecného skeletonu a jeho úpravami.

...protože v sysvinitu DRY neznamená Don't Repeat Yourself, ale Do Repeat Yourself...

[Pavel]

Tyjo. Kdyby se radsi Linux inspiroval napriklad u OpenBSD, kde jsou rc skripty reseny krasne, jednoduse a unix-style. Ano, sysvinit v Linuxu byl/je zpraseny, ale to nenapravis jinou zpraseninou (ikdyz o neco malo min zprasenou).

[marbu]

To je fakt, OpenBSD initskripty jsou stručné, bez nabdytečné funkcionality a duplikace kódu.

Jen tak pro zajímavost, ukázka iniskriptů z OpenBSD (BSD), CentOS (SysV via Upstart) a pak z Fedory (systemd). Je sice fakt, že SysV init skript řeší oproti BSD variantě mnohem víc věcí, ale zda je to tak dobře je k zvážení (otázka politiky dané distribuce).

#!/bin/sh
#
# $OpenBSD: sshd,v 1.2 2013/02/05 00:26:31 halex Exp $

daemon="/usr/sbin/sshd"

. /etc/rc.d/rc.subr

rc_reload() {
        ${daemon} ${daemon_flags} -t && pkill -HUP -f "^${pexp}"
}

rc_cmd $1

#!/bin/bash
#
# sshd		Start up the OpenSSH server daemon
#
# chkconfig: 2345 55 25
# description: SSH is a protocol for secure remote shell access. \
#              This service starts up the OpenSSH server daemon.
#
# processname: sshd
# config: /etc/ssh/ssh_host_key
# config: /etc/ssh/ssh_host_key.pub
# config: /etc/ssh/ssh_random_seed
# config: /etc/ssh/sshd_config
# pidfile: /var/run/sshd.pid

### BEGIN INIT INFO
# Provides: sshd
# Required-Start: $local_fs $network $syslog
# Required-Stop: $local_fs $syslog
# Should-Start: $syslog
# Should-Stop: $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start up the OpenSSH server daemon
# Description:       SSH is a protocol for secure remote shell access.
#		     This service starts up the OpenSSH server daemon.
### END INIT INFO

# source function library
. /etc/rc.d/init.d/functions

# pull in sysconfig settings
[ -f /etc/sysconfig/sshd ] && . /etc/sysconfig/sshd

RETVAL=0
prog="sshd"
lockfile=/var/lock/subsys/$prog

# Some functions to make the below more readable
KEYGEN=/usr/bin/ssh-keygen
SSHD=/usr/sbin/sshd
RSA1_KEY=/etc/ssh/ssh_host_key
RSA_KEY=/etc/ssh/ssh_host_rsa_key
DSA_KEY=/etc/ssh/ssh_host_dsa_key
PID_FILE=/var/run/sshd.pid

runlevel=$(set -- $(runlevel); eval "echo \$$#" )

fips_enabled() {
	if [ -r /proc/sys/crypto/fips_enabled ]; then
		cat /proc/sys/crypto/fips_enabled
	else
		echo 0
	fi
}

do_rsa1_keygen() {
	if [ ! -s $RSA1_KEY -a `fips_enabled` -eq 0 ]; then
		echo -n $"Generating SSH1 RSA host key: "
		rm -f $RSA1_KEY
		if test ! -f $RSA1_KEY && $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then
			chmod 600 $RSA1_KEY
			chmod 644 $RSA1_KEY.pub
			if [ -x /sbin/restorecon ]; then
			    /sbin/restorecon $RSA1_KEY.pub
			fi
			success $"RSA1 key generation"
			echo
		else
			failure $"RSA1 key generation"
			echo
			exit 1
		fi
	fi
}

do_rsa_keygen() {
	if [ ! -s $RSA_KEY ]; then
		echo -n $"Generating SSH2 RSA host key: "
		rm -f $RSA_KEY
		if test ! -f $RSA_KEY && $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then
			chmod 600 $RSA_KEY
			chmod 644 $RSA_KEY.pub
			if [ -x /sbin/restorecon ]; then
			    /sbin/restorecon $RSA_KEY.pub
			fi
			success $"RSA key generation"
			echo
		else
			failure $"RSA key generation"
			echo
			exit 1
		fi
	fi
}

do_dsa_keygen() {
	if [ ! -s $DSA_KEY ]; then
		echo -n $"Generating SSH2 DSA host key: "
		rm -f $DSA_KEY
		if test ! -f $DSA_KEY && $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then
			chmod 600 $DSA_KEY
			chmod 644 $DSA_KEY.pub
			if [ -x /sbin/restorecon ]; then
			    /sbin/restorecon $DSA_KEY.pub
			fi
			success $"DSA key generation"
			echo
		else
			failure $"DSA key generation"
			echo
			exit 1
		fi
	fi
}

do_restart_sanity_check()
{
	$SSHD -t
	RETVAL=$?
	if [ $RETVAL -ne  0 ]; then
		failure $"Configuration file or keys are invalid"
		echo
	fi
}

start()
{
	[ -x $SSHD ] || exit 5
	[ -f /etc/ssh/sshd_config ] || exit 6
	# Create keys if necessary
	if [ "x${AUTOCREATE_SERVER_KEYS}" != xNO ]; then
		do_rsa1_keygen
		do_rsa_keygen
		do_dsa_keygen
	fi

	echo -n $"Starting $prog: "
	$SSHD $OPTIONS && success || failure
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
	echo
	return $RETVAL
}

stop()
{
	echo -n $"Stopping $prog: "
	killproc -p $PID_FILE $SSHD
	RETVAL=$?
	# if we are in halt or reboot runlevel kill all running sessions
	# so the TCP connections are closed cleanly
	if [ "x$runlevel" = x0 -o "x$runlevel" = x6 ] ; then
	    trap '' TERM
	    killall $prog 2>/dev/null
	    trap TERM
	fi
	[ $RETVAL -eq 0 ] && rm -f $lockfile
	echo
}

reload()
{
	echo -n $"Reloading $prog: "
	killproc -p $PID_FILE $SSHD -HUP
	RETVAL=$?
	echo
}

restart() {
	stop
	start
}

force_reload() {
	restart
}

rh_status() {
	status -p $PID_FILE openssh-daemon
}

rh_status_q() {
	rh_status >/dev/null 2>&1
}

case "$1" in
	start)
		rh_status_q && exit 0
		start
		;;
	stop)
		if ! rh_status_q; then
			rm -f $lockfile
			exit 0
		fi
		stop
		;;
	restart)
		restart
		;;
	reload)
		rh_status_q || exit 7
		reload
		;;
	force-reload)
		force_reload
		;;
	condrestart|try-restart)
		rh_status_q || exit 0
		if [ -f $lockfile ] ; then
			do_restart_sanity_check
			if [ $RETVAL -eq 0 ] ; then
				stop
				# avoid race
				sleep 3
				start
			else
				RETVAL=6
			fi
		fi
		;;
	status)
		rh_status
		RETVAL=$?
		if [ $RETVAL -eq 3 -a -f $lockfile ] ; then
			RETVAL=2
		fi
		;;
	*)
		echo $"Usage: $0 {start|stop|restart|reload|force-reload|condrestart|try-restart|status}"
		RETVAL=2
esac
exit $RETVAL

[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

[Unit]
Description=OpenSSH Server Key Generation
ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key
ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key

[Service]
ExecStart=/usr/sbin/sshd-keygen
Type=oneshot

[trekker.dk]

Generování SSH klíče jako samostatná služba... moc pěkná obludnost.

[Honza Jaroš]

+1

Tohle by mě zajímalo - je v systemd nějak řešitelný úkol "když neexistují klíče, vygeneruj nové"? Skript z CentOS přesně tohle dělá...

[JS1]

Mozna jsem neco nepochopil, ale vzdyt tam ten priklad mas?

[Honza Jaroš]

Buď jste něco nepochopil vy, nebo já.

Podle mě ta unita jednou vygeneruje klíče a tím to hasne (čili postup, jaký praktikuje třeba Debian - tam se ovšem negenerují při prvním startu, nýbrž při instalaci). Skript z CentOS si zkontroluje, jestli klíče existují a v případě jejich neexistence (a pokud neexistuje /proc/sys/crypto/fips_enabled nebo tam je nulová hodnota) je vytvoří znovu při každém startu SSH démona. Já se ptal na ten druhý případ.

[Pavel]

Mam pocit ze v tom sshd unit souboru to je jako preexec, cili afaik se to spousti pred kazdym spustenim. Dependency hell, celkem chapu ze jsi to prehlidl...

[Honza Jaroš]

Aha, tak to je jiná. Díky.

[Pavel]

Aha, mmnt, tak ono to mozna bude jeste trosku jinak. Me se zda, ze ta sshd unita spousti prikaz sshd-keygen a ne unitu sshd keygen... Tyjo, zlaty shell skripty, tam to aspon je jasny a citelny.

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[Pavel]

Jestli sem to spravne pochopil, tak pred kazdym spustenim sshd se systemd snazi vygenerovat klice pokud neexistujou? Jestli jo, tak je to celkem doooost prasarna.

[JS1]

Ale to dela i ten skript, ne? (Tedy, technicky vzato, kouka se na jiny soubor, ale to muze byt proste rozdilem v distribuci.)

[Pavel]

LOL. Vy zase bijete cernochy! Sem myslel ze systemd se bude snazit veci opravit a ne odstranit to dobry, nechat to spatny, a navrch pridat nejaky svoje novy prasarny...

[JS1]

No LOL, jak to tedy ma spravne delat?

[Pavel]

O to by se v prvni rade nemel vubec snazit. Vygenerovat klice by mel pri instalaci/prvnim bootu.

[Honza Jaroš]

Záleží na úhlu pohledu. Pokud v CentOS/Gentoo potřebuju přegenerovat klíče (třeba když dělám kopii kontejneru v rámci OpenVZ/LXC), prostě je jen smažu a restartuju službu. V Debianu to musím udělat ručně.

Vidíte v tom nějaký bezpečnostní problém? Protože já vcelku ne - samovolně se ty klíče nesmažou a pokud je někdo smaže omylem, prostě jen začnou nadávat klienti. Jestli jsem něco přehlédl, prosil bych o vysvětlení...

[Heron]

Já nevím, mě vždy učili že každá funkce má dělat pouze jednu věc. Od funkce restartovat očekávám restartovat, a ne restartovat a podle pozice hvězd vygeneruj klíče. Z tohoto důvodu mi přijde logičtější to mít rozdělené na dvě funkce.

[Honza Jaroš]

Jak píšu, záleží na úhlu pohledu. Důvody pro hezky popsal pode mnou pavlix...

[JS1]

No tak pokud se vam to (v systemu se systemd) nelibi, muzete si tu jednu radku z te SSH unity zakomentovat a mate to. Ja fakt nevidim, proc by mel systemd predstavovat problem.

[pavlix]

Takhle to mám ve Fedoře 18, což dokazuje, že k tomu systemd poskytuje prostředky.

$ cat sshd.service 
[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process

[Install]
WantedBy=multi-user.target

Na druhou stranu v rawhide existuje samostatná služba pro generování klíče, ale nenechte se zmást. Při klasickém použití SSH démona se nepoužije, sshd.service vypadá pořád víceméně stejně jako výše a na sshd-keygen.service momentálně vůbec nezávisí.

[Unit]
Description=OpenSSH Server Key Generation
ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key
ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key

[Service]
ExecStart=/usr/sbin/sshd-keygen
Type=oneshot

Samostatná služba se používá při inetd-style socketové aktivaci jednotlivých sshd sessions, což je služba sshd@.service.

[Unit]
Description=OpenSSH per-connection server daemon
Wants=sshd-keygen.service
After=auditd.service sshd-keygen.service

[Service]
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=-/usr/sbin/sshd -i $OPTIONS
StandardInput=socket

Histerické reakce mého jmenovce mi nepřijdou na místě. Jsou jen dvě možnosti, co může SSH při startu při absenci klíčů dělat. Vygenerovat je nebo se ukončit s chybou. Generování má jednu obrovskou výhodu, a to že lze distribuovat hotový image s nainstalovaným SSH, který ale netrpí zásadní bezpečnostní chybou, kterou by předinstalované klíče způsobily, a zároveň je schopný se spustit. U mnohých zařízení je přístup pomocí SSH naprosto klíčový. Samostatná služba by se mu mohla líbit o to víc, protože po odstranění tvrdé závislosti by pak bylo možné tuto službu jednoduše zapnout/vypnout/odstranit dle ctěného přání. Což je vlastně i odpověď trekker.dk, proč to může mít smysl takto udělat.

[Heron]

Jsou jen dvě možnosti, co může SSH při startu při absenci klíčů dělat.

To je pravda, ale ještě před startem služby ssh se může startovat skript, který zkontroluje existenci a případně vygeneruje neexistující klíče. Tato funkce se nemusí obfuskovat za (re)start služby ssh.

[pavlix]

To je pravda, ale ještě před startem služby ssh se může startovat skript

O této možnosti jsem psal. Zda to udělá binárka nebo systemd na základě s binárkou distribuovaném .service považuju za implementační detail.

[Honza Jaroš]

Jsou jen dvě možnosti, co může SSH při startu při absenci klíčů dělat. Vygenerovat je nebo se ukončit s chybou.

Jak jsem si teď ověřil, sedmičkový Debian volí ještě třetí cestu: vypíše chybové hlášky o absenci klíčů a pak SSH normálně nastartuje bez nich se statusem OK...

[pavlix]

Hezké. Měl jsem ve skutečnosti namysli dvě rozumné věci. Nastartovat bez chyby nefunkční službu je z těch horších možností.

[kavol]

myslímže pointa celé diskuse ale není tak úplně o tom, jestli generovat klíče automaticky je nebo není dobrý nápad, nýbrž spíše o tom, jak zpraseně to verze se systemd řeší

zatímco původní skript volá generování klíčů jen když neexistují, systemd verze to volá při každém startu služby

a to je IMO neskutečná prasárna, a ještě navíc je to dvojnásob vtipné v kombinaci s tím, jak se systemd chlubil šetřením spouštěných procesů, zejména toho strašně pomalého bashe - přičemž /usr/sbin/sshd-keygen není nic jiného než bashový skript, co přebral kus funkcionality původního initskriptu ...

[Michal Vyskočil]

myslímže pointa celé diskuse ale není tak úplně o tom, jestli generovat klíče automaticky je nebo není dobrý nápad, nýbrž spíše o tom, jak zpraseně to verze se systemd řeší

zatímco původní skript volá generování klíčů jen když neexistují, systemd verze to volá při každém startu služby

Akorát, že zrovna unita o pár řádků níž ukazuje, že systemd spouštět binárku pouze pokud soubor neexistuje umí. Že to tak sshd.service nedělá je jiná věc - když nepodmíněné volání nacpeš do init skriptu, taky to neznamená, že je bash zprasený.

[kavol]

Akorát, že zrovna unita o pár řádků níž ukazuje, že systemd spouštět binárku pouze pokud soubor neexistuje umí.

to se ovšem týká spuštění služby samotné, nikoli toho, co je v ExecStartPre

Že to tak sshd.service nedělá je jiná věc - když nepodmíněné volání nacpeš do init skriptu, taky to neznamená, že je bash zprasený.

viz výše, v bashi je ten test před tím než se zavolají rutiny na generování klíčů, v systemd verzi se to volá bezpodmínečně, a teprve potom se řeší, jestli je to skutečně potřeba ... což nevím(*), jak lze řešit, jestli lze takovou podmínku uvalit na závislosti služby, a pokud neukážeš, že lze (nebo aspoň na to ExecStartPre), tak prozměnu nelze dovodit, že systemd není zprasený

jinými slovy, otázka nezní, jestli lze v bashi prasit, nýbrž jestli lze tu - podle tebe zprasenou - unitu přepsat tak, aby to zprasené nebylo

(*) zdůrazňuju: nevím, netvrdím že nelze, a pokud to tak vyznělo dříve, tak to nebylo účelem, popisoval jsem aktuální stav

[pavlix]

Pokud chceš čistý způsob, podívej se na tu druhou ukázku, kde je samostatný sshd-keygen.service. Ještě by teda bylo záhodno zrušit ten bashovský skript a zapracovat ho do té jednotky. Pokud bys pak použil nějaký generátor initskriptů, tak ti to vygeneruje něco, co je mnohem blíž tomu Gentoo initscriptu.

[kavol]

nezlob se, ale já v těch ukázkách opravdu nevidím, jak sshd může podmíněně (dle ne/existence klíčů) záviset na sshd-keygen, ať to čtu odpředu dozadu nebo zpět, tak tam vidím jenom možnost nepodmíněné závislosti - v dokumentaci nevidím ani slůvko o možnosti použít něco jako je na úrovni unity to ConditionPathExists

[kralyk z abclinuxu]

nezlob se, ale já v těch ukázkách opravdu nevidím, jak sshd může podmíněně (dle ne/existence klíčů) záviset na sshd-keygen, ať to čtu odpředu dozadu nebo zpět, tak tam vidím jenom možnost nepodmíněné závislosti

Samozřejmě, že ta závislost není podmíněná, na službě sshd-keygen to závisí vždy. Fór je v tom, že v případě, že ty klíče existujou, ta služba nic nespustí. Všimni si, že to je ekvivalentní tomu bash skriptu - tam se také pokaždé zavolá ta funkce do_*_keygen(), která na začátku má if.

[kavol]

Fór je v tom, že v případě, že ty klíče existujou, ta služba nic nespustí.

ó nikoli, spustí se ta služba samotná, že ta pak již nic dalšího nespustí, je jiná věc

Všimni si, že to je ekvivalentní tomu bash skriptu - tam se také pokaždé zavolá ta funkce do_*_keygen(), která na začátku má if.

a to je právě ta chyba, na kterou poukazuju - čistší by bylo, kdyby v tom skriptu byl if před voláním funkce a ne uvnitř tak, že obaluje celý obsah, ale z hlediska chodu skriptu je to jedno

u aktuálního řešení nad systemd to jedno není, neboť se naprosto zbytečně pustí bash jen aby vyhodnotil nesplněnou podmínku a udělal to "nic"

u řešení nad systemd, o kterém se tu bavíme, tedy formou závislosti, je to o něco lepší v tom, že tu podmínku vyhodnocuje systemd a ten bash tedy spustit nemusí, stále je tam ale režie se spouštěním další služby - a nejde ani tak o ten zanedbatelný zlomek strojového času, jestli to umí systemd zvládnout rychleji či pomaleji než bash odskok do funkce, jako spíše o celkové zesložitění procesu, i pro admina

kdyby systemd uměl ty svoje podmínky na úrovni StartExecPre a ne celé unity, bylo by to IMO daleko elegantnější

[pavlix]

ó nikoli, spustí se ta služba samotná, že ta pak již nic dalšího nespustí, je jiná věc

To je otázka úhlu pohledu, lepší bude mluvit v technických pojmech, nikoliv vágních představách. Nespustí se ten shellovský skript, o kterém tu byla řeč a jehož pomalost jsi kritizoval. Dokonce nedojde k žádné jiné diskové operaci než je ten stat na ty soubory, který tam chceme. Tedy z hlediska efektivity to dělá přesně to, co chceme. Z hlediska přehlednosti dle mého osobního názoru taktéž.

u aktuálního řešení nad systemd to jedno není, neboť se naprosto zbytečně pustí bash jen aby vyhodnotil nesplněnou podmínku a udělal to "nic"

Viz.

stále je tam ale režie se spouštěním další služby

Já bych řekl, že ta režie je vyfabulovaná.

jako spíše o celkové zesložitění procesu i pro admina

Mně to přijde jako zpřehlednění a z pohledu admina i zjednodušení, protože se může dívat na tu službu jako celek a nemusí řešit její implementační detaily. Jakožto vcelku zkušený admin to vidím v ideálním případě (řešení navržené v bugu) asi takto:

Jo, takže ten ssh server (sshd.service) závisí na key generátoru (sshd-keygen.service) a rozběhne se až po něm. Takže když si připravím image bez klíčů, tak se při prvním bootu vyrobí a SSH se rozběhne už s nima.

[kavol]

ó nikoli, spustí se ta služba samotná, že ta pak již nic dalšího nespustí, je jiná věc

To je otázka úhlu pohledu, lepší bude mluvit v technických pojmech, nikoliv vágních představách.

to by mě zajímalo, z jakého úhlu pohledu to lze vidět tak, že se systemd nepokusí spustit sshd-keygen.service, a teprve při jejím zpracování nenarazí na to, že podmínka není splněna, a tudíž samotný skript už nespustí ...

Nespustí se ten shellovský skript, o kterém tu byla řeč a jehož pomalost jsi kritizoval.

... ve zcela jiném kontextu!

Dokonce nedojde k žádné jiné diskové operaci než je ten stat na ty soubory, který tam chceme.

co prosím? a obsah sshd-keygen.service zjistí systemd jak, z křišťálové koule když ne z disku?

u aktuálního řešení nad systemd to jedno není, neboť se naprosto zbytečně pustí bash jen aby vyhodnotil nesplněnou podmínku a udělal to "nic"

Viz.

a? - to má být jako na vysvětlenou toho "zcela zbytečně", že to není zbytečné, ale že je to tak záměrně, protože bug #810419#c4?

stále je tam ale režie se spouštěním další služby

Já bych řekl, že ta režie je vyfabulovaná.

a já bych řekl, že jsi asi upadl na hlavičku, jinak si nedovedu tyhle tvoje kydy vysvětlit, viz výše nesmysl o diskových operacích ... to jsem si vyfabuloval, že se soubor prvně musí načíst, aby se mohla vyhodnotit podmínka v něm obsažená? fakt? OMG ...

Mně to přijde jako zpřehlednění a z pohledu admina i zjednodušení, protože se může dívat na tu službu jako celek a nemusí řešit její implementační detaily. Jakožto vcelku zkušený admin to vidím v ideálním případě (řešení navržené v bugu) asi takto:

Jo, takže ten ssh server (sshd.service) závisí na key generátoru (sshd-keygen.service) a rozběhne se až po něm. Takže když si připravím image bez klíčů, tak se při prvním bootu vyrobí a SSH se rozběhne už s nima.

WTF? tohle má být zpřehlednění proti situaci "prostě pustím sshd a nic dalšího nemusím řešit"?

[pavlix]

to by mě zajímalo, z jakého úhlu pohledu to lze vidět tak, že se systemd nepokusí spustit sshd-keygen.service, a teprve při jejím zpracování nenarazí na to, že podmínka není splněna

Opět používáš vágní až nesmyslnou terminologii. Ten soubor, o kterém mluvíš, sshd-keygen.service je konfigurační soubor načítaný při startu systemd, nikoliv nějaký spustitelný soubor. Pokud máš pocit, že načtení jednoho konfiguračního souboru během startu navíc je nezanedbatelný overhead, asi bys měl přijít s nějakými čísly.

a já bych řekl, že jsi asi upadl na hlavičku

A ty mě budeš poučovat o věcnosti. Co kdybys nejdřív předvedl odpovídající odborné znalosti a schopnosti, a pak teprve někomu nadával?

to jsem si vyfabuloval, že se soubor prvně musí načíst, aby se mohla vyhodnotit podmínka v něm obsažená? fakt? OMG ...

Jak se to vezme. Ten soubor se pokud vím načítá při startu systemd nebo při reload systemd, což by navíc měla být docela dobře měřitelná akce. Ten soubor je velmi malý, jeho formát triviální, při běžném provozu se načítá a parsuje jenom jednou. To všechno přispívá k tomu, že musím vyjádřit pochybnost, že jeden soubor navíc, potažmo deset až patnáct takových souborů pro další služby se stejnými potřebami, předtavuje nezanedbatelný overhead nebo overhead srovnatelný se spouštěním shellovských skriptů.

WTF? tohle má být zpřehlednění proti situaci "prostě pustím sshd a nic dalšího nemusím řešit"?

Na tom se snad něco změnilo? Následující příkaz pro klasickou službu funguje pořád naprosto stejně:

service sshd start

Způsobí vygenerování klíčů, pokud ještě vygenerované nejsou, a spuštění SSH serveru.

[kavol]

to by mě zajímalo, z jakého úhlu pohledu to lze vidět tak, že se systemd nepokusí spustit sshd-keygen.service, a teprve při jejím zpracování nenarazí na to, že podmínka není splněna

Opět používáš vágní až nesmyslnou terminologii.

prosím, máš prostor vytasit se s tou správnou

Ten soubor, o kterém mluvíš, sshd-keygen.service je konfigurační soubor načítaný při startu systemd, nikoliv nějaký spustitelný soubor.

nikoli "ten soubor", ale "ta služba" ("jejím", ne "jeho") - nauč se číst

Pokud máš pocit, že načtení jednoho konfiguračního souboru během startu navíc je nezanedbatelný overhead, asi bys měl přijít s nějakými čísly.

viz výše, nebavil jsem se o tom, kdy se to děje, ale že se to děje zbytečně, a žádné kecy o (ne)zanedbatelnosti na tom nic nemění

a já bych řekl, že jsi asi upadl na hlavičku

A ty mě budeš poučovat o věcnosti. Co kdybys nejdřív předvedl odpovídající odborné znalosti a schopnosti, a pak teprve někomu nadával?

eh? jaké odborné znalosti a schopnosti mám předvádět, abych si mohl dovolit tvrdit, že u v současnosti nejrozšířenější koncepce počítačů a jejich OS se musí data, se kterými program pracuje, nejprve načíst z jejich úložiště, aby se podle nich mohl řídit program, a že konání činnosti před vyhodnocením podmínky, tedy pokaždé, sežere víc procesorového času a vůbec prostředků, nežli koná-li se tatáž činnost teprve po vyhodnocení podmínky, tedy jenom někdy?

to jsem si vyfabuloval, že se soubor prvně musí načíst, aby se mohla vyhodnotit podmínka v něm obsažená? fakt? OMG ...

Jak se to vezme. Ten soubor se pokud vím načítá při startu systemd nebo při reload systemd, což by navíc měla být docela dobře měřitelná akce. Ten soubor je velmi malý, jeho formát triviální, při běžném provozu se načítá a parsuje jenom jednou. To všechno přispívá k tomu, že musím vyjádřit pochybnost, že jeden soubor navíc, potažmo deset až patnáct takových souborů pro další služby se stejnými potřebami, předtavuje nezanedbatelný overhead nebo overhead srovnatelný se spouštěním shellovských skriptů.

viz výše, že je něco malé, nebo že v USA bijou černochy, ještě neznamená, že to neexistuje

WTF? tohle má být zpřehlednění proti situaci "prostě pustím sshd a nic dalšího nemusím řešit"?

Na tom se snad něco změnilo?

no, podle tvojí předchozí reakce ano, začal jsi řešit tu závislost na další službě ...

Následující příkaz pro klasickou službu funguje pořád naprosto stejně:

service sshd start

Způsobí vygenerování klíčů, pokud ještě vygenerované nejsou, a spuštění SSH serveru.

to sice ano, ale řeč byla o tom, že "Mně to přijde jako zpřehlednění a z pohledu admina i zjednodušení, protože se může dívat na tu službu jako celek a nemusí řešit její implementační detaily.", přičemž realitou je pravý opak - v systemctl list-unit-files je kvůli tomu víc bordelu, položka, jejíž ekvivalent jsi v chkconfig řešit nemusel

[pavlix]

Já osobně se radši zabývám reálnými problémy než řešením toho, že se (podle tebe zbytečně) načítá jeden krátký soubor navíc.

[kralyk z abclinuxu]

ó nikoli, spustí se ta služba samotná, že ta pak již nic dalšího nespustí, je jiná věc

Nevím, jestli jsi to zaznamenal, ale .service není spustitelný soubor. Stane se pouze to, že systemd načte sshd-keygen.service (který už stejně pravděpodobně je načtený - viz pavlix), zkontroluje existenci souborů, a následně nic neudělá, když existují.

Ve skutečnosti spouští víc věcí ten bash skript - všimni si, že forkuje ve funkci start (řádek 141 - příkaz touch) a několikrát ve funkci stop (ř. 194, 149, 155, 158).

a to je právě ta chyba, na kterou poukazuju - čistší by bylo, kdyby v tom skriptu byl if před voláním funkce a ne uvnitř tak, že obaluje celý obsah, ale z hlediska chodu skriptu je to jedno

To je daný tím, že .service soubory jsou čistě deskriptivní, není to imperativní kód. Oboje má svoje pro a proti.

u aktuálního řešení nad systemd to jedno není, neboť se naprosto zbytečně pustí bash jen aby vyhodnotil nesplněnou podmínku a udělal to "nic"

Nějak nevidím, kde se tam spouští bash - bavíme se doufám o tom řešení s ConditionPathExists? No i kdyby ale ten bash jednou spustil, stále to imho nebude mít větší režii než ten init skript.

Já nevim, o čem se tu hádáme - obvykle i odpůrci systemd uznávají, že rychlý je.

[kavol]

ó nikoli, spustí se ta služba samotná, že ta pak již nic dalšího nespustí, je jiná věc

Nevím, jestli jsi to zaznamenal, ale .service není spustitelný soubor.

a? já jsem řekl, že se spustí ten soubor? nebo celou dobu mluvím o službě?

Stane se pouze to, že systemd načte sshd-keygen.service (který už stejně pravděpodobně je načtený - viz pavlix),

pointa není v tom, jestli se načte právě teď, nebo už v paměti hnije(*), nýbrž že se vůbec musí načíst; podle pavlixe se ovšem zřejmě v té paměti jen tak vyskytne bez přístupu na disk

(*) což by ovšem bylo řešení ještě obludnější ...

zkontroluje existenci souborů, a následně nic neudělá, když existují.

bavím se o tom, co udělá před tím "nic"

Ve skutečnosti spouští víc věcí ten bash skript - všimni si, že forkuje ve funkci start (řádek 141 - příkaz touch) a několikrát ve funkci stop (ř. 194, 149, 155, 158).

a teď ještě prosím vysvětlení, jak tyto řádky souvisí s tou částí problému startu sshd, o které se tu bavíme, tedy (ne)vytvářením klíčů?

a to je právě ta chyba, na kterou poukazuju - čistší by bylo, kdyby v tom skriptu byl if před voláním funkce a ne uvnitř tak, že obaluje celý obsah, ale z hlediska chodu skriptu je to jedno

To je daný tím, že .service soubory jsou čistě deskriptivní, není to imperativní kód. Oboje má svoje pro a proti.

nerozumím, co tím básník chtěl říci v souvislosti s mým tvrzením, že je chybou takto srovnávat chování unity se skriptem, notabene když ten skript je určitým způsobem zprasený?

u aktuálního řešení nad systemd to jedno není, neboť se naprosto zbytečně pustí bash jen aby vyhodnotil nesplněnou podmínku a udělal to "nic"

Nějak nevidím, kde se tam spouští bash - bavíme se doufám o tom řešení s ConditionPathExists?

haú ... mluvil jsem jasně o dvou variantách, "aktuální řešení" a "řešení o kterém se bavíme, tedy formou závislosti", řekl jsem jasně, že druhé je jiné než prvé, a přesto sis neráčil všimnout, že to není jedno a totéž, a pod prvé mi cpeš reakci nad druhé? seš zfetovanej?

aktuální řešení viz výše:

[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service
 
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
 
[Install]
WantedBy=multi-user.target

No i kdyby ale ten bash jednou spustil, stále to imho nebude mít větší režii než ten init skript.

viz výše, bude to mít větší režii než ta část skriptu, která řeší problém klíčů

Já nevim, o čem se tu hádáme - obvykle i odpůrci systemd uznávají, že rychlý je.

o další "design flaw"

[pavlix]

a? já jsem řekl, že se spustí ten soubor? nebo celou dobu mluvím o službě?

Vyjádření spustí se služba jak vidíš není dostatečně jednoznačné a z hlediska efektivity není ani moc zajímavé.

podle pavlixe se ovšem zřejmě v té paměti jen tak vyskytne bez přístupu na disk

Co kdybysis mě nebral do huby pokaždé, když ti chybí argument?

což by ovšem bylo řešení ještě obludnější ...

Právě naopak. Načíst celou konfiguraci při startu je velmi efektivní a v unixovém, linuxovém i BSD světě zcela běžné. Zda je konfigurace sesypána do jednoho souboru nebo rozdělena mezi více, je druhá věc.

haú ... mluvil jsem jasně o dvou variantách, "aktuální řešení" a "řešení o kterém se bavíme, tedy formou závislosti", řekl jsem jasně, že druhé je jiné než prvé, a přesto sis neráčil všimnout, že to není jedno a totéž, a pod prvé mi cpeš reakci nad druhé?

Mám za to, že nemluvíš dostatečně jasně o dvou variantách a nespecifikuješ, o kterou variantu se jedná. Na druhou stranu, kdybys to specifikoval, tak se s tebou nikdo o aktuální variantě bavit nebude, protože se jedná o zjevně neoptimální řešení na straně SSH balíku a už nějakou dobu existuje bug report na jeho nápravu.

Věc se má tak, že pokud chceš použít neoptimální řešení na straně balíku jako technickou argumentaci proti systemd, tak tě člověk při smyslech nemůže brát vážně. A to ani kdyby to byl sebevětší odpůrce systemd. Jenom podporuješ tu teorii o tom, že odpůrci nemají v ruce žádné dobré argumenty, a nepřímo tím pomáháš systemd (pokud by teda kecy na Abclinuxu měly sílu něco změnit). Děláš tu akorát ostudu jak zastáncům OpenRC, tak i zastáncům klasických initscriptů, a vůbec komukoliv, kdo chce přijít s relevantní kritikou vůči systemd.

A dost mě to mrzí u tak chytrého člověka, jako jsi ty, který by při troše sebeovládání mohl být jak argumentačně, tak přínosem linuxové komunitě na úplně jiné úrovni.

seš zfetovanej?

Jenom blbec si myslí, že nadávky přidají jeho slovům na vážnosti. Takže bych moc rád věděl, jaká je tvoje motivace se takhle projevovat.

[kavol]

hele, jestli si trénuješ demagogii a diskusní podpásovky na opozici Lennartovi, tak ti to docela jde, mě to ale takhle moc nebere ...

a? já jsem řekl, že se spustí ten soubor? nebo celou dobu mluvím o službě?

Vyjádření spustí se služba jak vidíš není dostatečně jednoznačné

fajn, předveď jednoznačnější

a z hlediska efektivity není ani moc zajímavé.

?

podle pavlixe se ovšem zřejmě v té paměti jen tak vyskytne bez přístupu na disk

Co kdybysis mě nebral do huby pokaždé, když ti chybí argument?

hezký pokus, ale "viz pavlix" napsal kralyk

což by ovšem bylo řešení ještě obludnější ...

Právě naopak. Načíst celou konfiguraci při startu je velmi efektivní a v unixovém, linuxovém i BSD světě zcela běžné. Zda je konfigurace sesypána do jednoho souboru nebo rozdělena mezi více, je druhá věc.

já jsem ovšem za "ještě obludnější" neoznačil samotné načtení konfigurace, nýbrž její držení v paměti i když není potřeba

Mám za to, že nemluvíš dostatečně jasně o dvou variantách a nespecifikuješ, o kterou variantu se jedná.

a já mám za to, že teď účelově lžeš, viz ještě níže

Na druhou stranu, kdybys to specifikoval, tak se s tebou nikdo o aktuální variantě bavit nebude, protože se jedná o zjevně neoptimální řešení na straně SSH balíku a už nějakou dobu existuje bug report na jeho nápravu.

ROFL, ty jsi "nikdo", jestliže ten bug vznikl právě na základě toho, že ses o tom se mnou bavil?

dobře ty, Lennart^2

Věc se má tak, že pokud chceš použít neoptimální řešení na straně balíku jako technickou argumentaci proti systemd, tak tě člověk při smyslech nemůže brát vážně. A to ani kdyby to byl sebevětší odpůrce systemd. Jenom podporuješ tu teorii o tom, že odpůrci nemají v ruce žádné dobré argumenty, a nepřímo tím pomáháš systemd (pokud by teda kecy na Abclinuxu měly sílu něco změnit). Děláš tu akorát ostudu jak zastáncům OpenRC, tak i zastáncům klasických initscriptů, a vůbec komukoliv, kdo chce přijít s relevantní kritikou vůči systemd.

hezky jsi mi to nandal, jen kdybys přitom neignoroval diskusi právě té druhé varianty v tom původním příspěvku, zejména opakuju: kdyby systemd uměl ty svoje podmínky na úrovni StartExecPre a ne celé unity, bylo by to IMO daleko elegantnější - a to není "neoptimální řešení na straně balíku", nýbrž problém systemd

seš zfetovanej?

Jenom blbec si myslí, že nadávky přidají jeho slovům na vážnosti.

fajn, proč mi potom nadáváš do blbců?

Takže bych moc rád věděl, jaká je tvoje motivace se takhle projevovat.

takže za prvé, k tomu "takhle", "zfetovanej" narozdíl od "blbec" není nadávkou

za druhé, k té motivaci, skutečně mě zajímalo, co vedlo ke kralykově indispozici, jestliže si neráčí všimnout, začínám-li dva odstavce ve stylu "u řešení blabla" a "u řešení bleble", že "blabla" != "bleble"

[pavlix]

kdyby systemd uměl ty svoje podmínky na úrovni StartExecPre a ne celé unity, bylo by to IMO daleko elegantnější

Mně osobně to elegantnější nepřijde a současné řešení považuju za víc než vyhovující.

Jenom blbec si myslí, že nadávky přidají jeho slovům na vážnosti.

fajn, proč mi potom nadáváš do blbců?

Mám to chápat tak, že je podmínka splněna a ty skutečně věříš tomu, že nadávky přidají tvým slovům na vážnosti? To bys mě docela překvapil.

za druhé, k té motivaci, skutečně mě zajímalo, co vedlo ke kralykově indispozici, jestliže si neráčí všimnout, začínám-li dva odstavce ve stylu "u řešení blabla" a "u řešení bleble", že "blabla" != "bleble"

Já to chápu tak, že kralyk, stejně jako já, nesprávně předpokládal, že se s ním chceš bavit o vhodnosti/nevhodnosti systemd a tedy že nebudeš úmyslně argumentovat špatně navrženou konfigurací, když už byla v diskuzi popsána lepší varianta. Mám obavu, že jsi byl jediný člověk v diskuzi, který měl zájem se tou horší variantou nadále zabývat.

[kavol]

kdyby systemd uměl ty svoje podmínky na úrovni StartExecPre a ne celé unity, bylo by to IMO daleko elegantnější

Mně osobně to elegantnější nepřijde a současné řešení považuju za víc než vyhovující.

chápal bych to, kdybych věděl, že se vyžíváš v dependency hell ... doposud jsem ten dojem tak úplně neměl, ale já nejsem ten, kdo by si vedl kartotéky (zdravím Marfušu a m-traina )

Jenom blbec si myslí, že nadávky přidají jeho slovům na vážnosti.

fajn, proč mi potom nadáváš do blbců?

Mám to chápat tak, že je podmínka splněna a ty skutečně věříš tomu, že nadávky přidají tvým slovům na vážnosti? To bys mě docela překvapil.

hehe, čekal jsem, jakým způsobem se vykroutíš, že mi vlastně nenadáváš

přesně, jak jsem tě na začátku chválil, formuloval jsi ten útok tak, aby nebyl napadnutelný - nicméně ještě máš nedostatky, účinnější než přímé srovnání s chováním blbce je označit negativním cejchem jen to samotné chování a nechat čtenáře, ať si ten oslí můstek, že kdo se chová blbě, je blbec, podvědomě udělá sám, a pak to lépe přijme za své, když je to vlastně z jeho hlavy, nežli když mu to takto přímo naservíruješ

[pavlix]

Takže nám nezbylo z diskuze nic než prázdné řeči.

[kavol]

když jsme u toho, ještě stále se mi v cubiclu nevyskytla ta basa piva ...

[pavlix]

Budu na to myslet...

[kralyk z abclinuxu]

zejména opakuju: kdyby systemd uměl ty svoje podmínky na úrovni StartExecPre a ne celé unity, bylo by to IMO daleko elegantnější - a to není "neoptimální řešení na straně balíku", nýbrž problém systemd

Problém s podmínkou na úrovni StartExecPre by byl ten, že by to byl v podstatě if, z té unity by to dělalo v podstatě imperativní kód s větvením, byl by z toho skript. Tak to ale být nemá, systemd units nejsou init skripty, mají být čistě deskriptivní - deklrativní záležitost.

To by jinak už dávno byly napsány v nějakém obecném skriptovacím jazyce.

já jsem ovšem za "ještě obludnější" neoznačil samotné načtení konfigurace, nýbrž její držení v paměti i když není potřeba

Těch pár bajtů? Je fascinující, do jakých mikrooptimalizací se pouštíš, když jde o systemd. U shell init skriptů ti byl výkon úplně u zadku, tam se forkovalo na každým kroku, navíc bash typicky zpracovává všechno v textové podobě, ale nic z toho ti nijak nevadilo. U systemd ti najednou vadí i to, že drží pár bajtů v paměti (navíc bůhví, jestli to tak skutečně je)...

[kavol]

Problém s podmínkou na úrovni StartExecPre by byl ten, že by to byl v podstatě if, z té unity by to dělalo v podstatě imperativní kód s větvením, byl by z toho skript. Tak to ale být nemá, systemd units nejsou init skripty, mají být čistě deskriptivní - deklrativní záležitost.

ehm, ale to větvení tam stejně je, akorát o unitu dál ...

To by jinak už dávno byly napsány v nějakém obecném skriptovacím jazyce.

mno, praxe nám ukazuje, že těch "corner cases" je tolik a jsou natolik významné, že je jednodušší skriptovat, než vymejšlet rovnáky na vohejbáky jako v případě systemd

Těch pár bajtů? Je fascinující, do jakých mikrooptimalizací se pouštíš, když jde o systemd. U shell init skriptů ti byl výkon úplně u zadku, tam se forkovalo na každým kroku, navíc bash typicky zpracovává všechno v textové podobě, ale nic z toho ti nijak nevadilo. U systemd ti najednou vadí i to, že drží pár bajtů v paměti (navíc bůhví, jestli to tak skutečně je)...

pár bajtů sem, pár bajtů tam ...

jsou tu dva aspekty - ten technický, že je rozdíl mezi nějakou víceméně jednorázovou záležitostí (já tedy za běhu systému typicky nerestartuju ssh démona co pár milisekund nebo tak něco), a tím, když to někde hnije po celou dobu běhu systému

a druhý politický - jestliže se borec chlubí tím, jak systemd ty prostředky šetří, tak by ten návrh teda sakra měl vypadat jinak ... mně je ten výkon u zadku vpodstatě pořád, jen nemám rád příliš velké rozdíly mezi slovy a činy

nicméně dovedu si představit, že některým to až tak u zadku být nemusí, jestliže tu Jirka psal o aplikaci s Raspberry Pi, to má nějakých 256 MiB RAM sdílených, a jestliže celá konfigurace (míněno všechny unity, pak jsou ještě další věci ...) maj nějaký asi mega, tak to už není tak úplně nezanedbatelnej rozdíl, jestli se to drží v paměti nebo ne

[pavlix]

mno, praxe nám ukazuje, že těch "corner cases" je tolik a jsou natolik významné, že je jednodušší skriptovat, než vymejšlet rovnáky na vohejbáky jako v případě systemd

Praxe lze interpretovat různě.

Popravdě mi na správci služeb v systemd vadí spíše uživatelská strana a to, že správce vůbec musí při práci rozlišovat služby aktivované pomocí socketu a ostatní, než API pro služby, které mi v současné době přijde vcelku vyvážené. Ale to je očividně věc názoru.

ten technický, že je rozdíl mezi nějakou víceméně jednorázovou záležitostí (já tedy za běhu systému typicky nerestartuju ssh démona co pár milisekund nebo tak něco), a tím, když to někde hnije po celou dobu běhu systému

Rozlišení mezi krátkodobým a dlouhodobým zabráním paměti považuju za validní argument. Na druhou stranu bych správce služeb asi chtěl i kdyby to mělo znamenat 1/256 zabrané RAM, a stejně tak bych chtěl, aby si konfiguraci držel v RAM a nemusel ji při každé příležitosti znovu načítat a parsovat.

a druhý politický - jestliže se borec chlubí tím, jak systemd ty prostředky šetří, tak by ten návrh teda sakra měl vypadat jinak

To si právě nemyslím.

maj nějaký asi mega, tak to už není tak úplně nezanedbatelnej rozdíl, jestli se to drží v paměti nebo ne

Pokud bych se měl zabývat optimalizací s ohledem na stroj s 256 a méně megabajtů RAM, moje snaha by se neubírala ani vstříc neudržování konfigurace v RAM, ani vstříc snižování počtu unit souborů o jednotky. Obojí mi připadá jako nesmysl.

[trekker.dk]

stejně tak bych chtěl, aby si konfiguraci držel v RAM a nemusel ji při každé příležitosti znovu načítat a parsovat.

Což je pěkně hloupé. Co je to ta "každá příležitost"? Zastavení/spuštění nějaké služby? To se tak často neděje, aby se kvůli tomu vyplatilo držet ta data v paměti; dvakrát tak to platí, pokud systém má málo paměti a zapnutý swap, protože pak ta paměť stejně bude odwapovaná.

A aby mě někdo nenařkl, že ignoruju speciální případy, kdy si někdo potřebuje restartovat služby každých pět minut - v takové situaci ty konfigurační soubory budou v page cache.

[pavlix]

Vůbec mi to hloupé nepřijde, právě naopak. Četnost té každé příležitosti závisí na konfiguraci, ale já osobně si myslím, že na té četnosti příliš nezáleží. Množství dat je úměrné komplexnosti daného systému, tudíž by v případě nějakého jednoúčelového zařízení mělo jít stlačit na minimum.

Radši bych šetřil procesorový čas a IO, klidně i relativně agresivně, pokud to bude stát jen malé množství RAM. Swapování nepovažuju v dnešní době za dobré řešení a sám používám swap víceméně jen kvůli uspávání a kvůli krizovým situacím. Načítání dat z diskové cache mi nepřijde nijak výhodné oproti držení hotových datových struktur v paměti. To už mi přijde lepší nechat ta nacachovaná data po startu vypršet a použít paměť k něčemu užitečnějšímu.

[trekker.dk]

Radši bych šetřil procesorový čas a IO, klidně i relativně agresivně, pokud to bude stát jen malé množství RAM.

Jednou za měsíc šetřil procesorový čas a I/O za cenu toho, že zbytek toho měsíce na systému s malým množstvím paměti zbytečně plýtvám a omezuji tedy ostatní aplikace. To je hloupé. Já ten systém provozuji kvůli aplikacím, ne kvůli init systému.

Načítání dat z diskové cache mi nepřijde nijak výhodné oproti držení hotových datových struktur v paměti

Rozdíl je v tom, že když ta data v diskové cache nejsou potřeba - protože se téměř nepoužívají - tak je jádro vyhodí a uvolněnou paměť použije k něčemu užitečnějšímu. Takže v případě častého přístupu mám data k dispozici rychle*, v případě méně častého se neplýtvá paměti, to všechno bez nutnosti řešit to v aplikaci.

* zanedbávám nutnost vygenerovat ty datové struktury, i pomalé procesory jsou na to dost rychlé.

[pavlix]

* zanedbávám nutnost vygenerovat ty datové struktury, i pomalé procesory jsou na to dost rychlé.

V tom případě zanedbávám tu využitou paměť. I malá paměť je dneska dost velká.

[trekker.dk]

No, na tom Raspberry zjevně nebyla. Nehledě na to, že je to furt jednou za dlouhou dobu procesorový čas proti využité paměti pořád

[pavlix]

No, na tom Raspberry zjevně nebyla.

Zjevně byla.

Nehledě na to, že je to furt jednou za dlouhou dobu procesorový čas proti využité paměti pořád

To nemusí být vždy lepší volba.

[kralyk z abclinuxu]

ehm, ale to větvení tam stejně je, akorát o unitu dál ...

To ale není větvení v rámci "kódu" té unity, to jsou podmínky celé té unity.

mno, praxe nám ukazuje, že těch "corner cases" je tolik a jsou natolik významné, že je jednodušší skriptovat, než vymejšlet rovnáky na vohejbáky jako v případě systemd

Jednodušší skriptovat? Ano, to jsem viděl na tom skriptu výše

jsou tu dva aspekty - ten technický, že je rozdíl mezi nějakou víceméně jednorázovou záležitostí (já tedy za běhu systému typicky nerestartuju ssh démona co pár milisekund nebo tak něco), a tím, když to někde hnije po celou dobu běhu systému

Prvně dokaž, že to skutečně někde hnije po celou dobu běhu systému. Osobně o tom silně pochybuju.

a druhý politický - jestliže se borec chlubí tím, jak systemd ty prostředky šetří, tak by ten návrh teda sakra měl vypadat jinak ... mně je ten výkon u zadku vpodstatě pořád, jen nemám rád příliš velké rozdíly mezi slovy a činy

Děláš si srandu? Tohle už je opravdu silně mimo systemd bootuje velmi rychle a v paměti zabírá minimum. Jestli chceš tohle rozporovat, tak si prosímtě přichystej nějaká reálná čísla / reálné benchmarky, ne nějaké mikrooptimalizace (jako je nenačtení jednoho malýho souboru), které by ve výsledku výkon nijak neovlivnily.

[kavol]

ehm, ale to větvení tam stejně je, akorát o unitu dál ...

To ale není větvení v rámci "kódu" té unity, to jsou podmínky celé té unity.

nerozumím, co tím chtěl básník říci ... prostě tam to "if", co ti vadí, je, jen na jiném místě

Jednodušší skriptovat? Ano, to jsem viděl na tom skriptu výše

nejsem si jist, co teď přesně myslíš, tedy kromě toho, že si chceš (neskutečně pitomě) rýpnout, nicméně připomněl bych, že ten kód se přenesl i do řešení nad systemd, jenom je teď v jiném souboru, takže v tomto ohledu žádná změna, jen to teď člověk musí lovit po všech čertech

jsou tu dva aspekty - ten technický, že je rozdíl mezi nějakou víceméně jednorázovou záležitostí (já tedy za běhu systému typicky nerestartuju ssh démona co pár milisekund nebo tak něco), a tím, když to někde hnije po celou dobu běhu systému

Prvně dokaž, že to skutečně někde hnije po celou dobu běhu systému. Osobně o tom silně pochybuju.

zajímavé, o kousek výše ti to přijde pravděpodobné: "Stane se pouze to, že systemd načte sshd-keygen.service (který už stejně pravděpodobně je načtený - viz pavlix),", a teď o tom silně pochybuješ a mám to dokazovat?

a druhý politický - jestliže se borec chlubí tím, jak systemd ty prostředky šetří, tak by ten návrh teda sakra měl vypadat jinak ... mně je ten výkon u zadku vpodstatě pořád, jen nemám rád příliš velké rozdíly mezi slovy a činy

Děláš si srandu? Tohle už je opravdu silně mimo

ano, já vím, dneska je mimo snažit se nenechat si lhát do očí, no ale v tomto případě mi tedy vůbec nevadí být mimoněm (no, tedy nevadí mi zastávat tuto pozici, jinak samozřejmě bych byl radši, kdyby to nebylo mimoňství ale mainstream, ale co už nadělám ...)

systemd bootuje velmi rychle a v paměti zabírá minimum. Jestli chceš tohle rozporovat, tak si prosímtě přichystej nějaká reálná čísla / reálné benchmarky, ne nějaké mikrooptimalizace (jako je nenačtení jednoho malýho souboru), které by ve výsledku výkon nijak neovlivnily.

# pmap 1
1:   /usr/lib/systemd/systemd --switched-root --system --deserialize 21
...
 total            49944K

# pmap 1
1:   init [3]
...
 total             4236K

[marbu]

Jen pro uplnost (ukazka z fedory 20):

# ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
 50908  3648  6640

Vyznam (viz man ps):

1. VSZ virtual memory size of the process in KiB (1024-byte units)
2. SIZE approximate amount of swap space that would be required if the process were to dirty all writable pages and then be swapped out.
3. RSS resident set size, the non-swapped physical memory that a task has used (inkiloBytes)

Takze jestli to ctu dobre, systemd mi v ram zabira skoro 7MB.

[kralyk z abclinuxu]

U mně:

$> ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
 31668  1372  1792

Nevim, proč to u mě zabírá o tolik míň. Mam Arch.

[little.owl]

Nevim, proč to u mě zabírá o tolik míň. Mam Arch.

SELinux?

[kralyk z abclinuxu]

nerozumím, co tím chtěl básník říci ... prostě tam to "if", co ti vadí, je, jen na jiném místě

To, že je na jiném místě - na jiné úrovni návrhu, je imho důležité.

nejsem si jist, co teď přesně myslíš, tedy kromě toho, že si chceš (neskutečně pitomě) rýpnout, nicméně připomněl bych, že ten kód se přenesl i do řešení nad systemd, jenom je teď v jiném souboru, takže v tomto ohledu žádná změna, jen to teď člověk musí lovit po všech čertech

Někdo tomu říká "o jeden soubor vedle", někdo "po všem čertech" Jinak init skripty (včetně toho výše) typicky používají externích souborů jeden nebo vícero, ale tam ti to nevadí (jako obvykle u sysvinitu).

zajímavé, o kousek výše ti to přijde pravděpodobné: "Stane se pouze to, že systemd načte sshd-keygen.service (který už stejně pravděpodobně je načtený - viz pavlix),", a teď o tom silně pochybuješ a mám to dokazovat?

Souvislost? Ty někde v tom komentáři vidíš "hnije v paměti po celou dobu běhu systému"? Já teda ne.

ano, já vím, dneska je mimo snažit se nenechat si lhát do očí

To je v perspektivě tvého porovnání toho init skriptu s tím unitem docela vtipné prohlášení, ale budiž...

# pmap 1
1:   /usr/lib/systemd/systemd --switched-root --system --deserialize 21
...
 total            49944K

V souladu s tvým doporučením o tom, že by si člověk neměl nechat lhát do očí, bych tě požádal odečíst od toho čísla všechny knihovny typu libc, libz, librt, libpthreads a další, které by byly načteny tak jako tak nějakým jiným procesem. Letmo jsem to skouknul, a myslím, že bychom se dostali na nějakých 4 až 10 MB, což imho vůbec není špatné porovnání...

[kavol]

nerozumím, co tím chtěl básník říci ... prostě tam to "if", co ti vadí, je, jen na jiném místě

To, že je na jiném místě - na jiné úrovni návrhu, je imho důležité.

podle mého taky, ale jinak :-p

tak si prostě nakresli nebo aspoň představ dva vývojové diagramy, jeden jak to půjde po opravení bugu, co pavlix hlásil, a druhý jak by to bylo s aktuální verzí kódu sshd.service, obohacenou o to, že by na tom ExecStartPre mohla být ta ConditionPath

vidíš mezi nimi nějaký principiální rozdíl co se týče možností větvení kódu?

Jinak init skripty (včetně toho výše) typicky používají externích souborů jeden nebo vícero, ale tam ti to nevadí (jako obvykle u sysvinitu).

eh, jak jsme to říkali s těmi černochy a júesej?

... no, konkrétně ten výše, používá snad více souborů než to řešení nad systemd (jakékoli ze zde diskutovaných)?

(tedy krom toho, že si sourcuje functions, což je prostě součástí initsystému)

zajímavé, o kousek výše ti to přijde pravděpodobné: "Stane se pouze to, že systemd načte sshd-keygen.service (který už stejně pravděpodobně je načtený - viz pavlix),", a teď o tom silně pochybuješ a mám to dokazovat?

Souvislost? Ty někde v tom komentáři vidíš "hnije v paměti po celou dobu běhu systému"? Já teda ne.

vidím tam ekvivalentní tvrzení, je-li načtený kdykoli se může zavolat start sshd ...

ano, já vím, dneska je mimo snažit se nenechat si lhát do očí

To je v perspektivě tvého porovnání toho init skriptu s tím unitem docela vtipné prohlášení, ale budiž...

to by si zasloužilo nějaký důkaz ...

# pmap 1
1:   /usr/lib/systemd/systemd --switched-root --system --deserialize 21
...
 total            49944K

V souladu s tvým doporučením o tom, že by si člověk neměl nechat lhát do očí, bych tě požádal odečíst od toho čísla všechny knihovny typu libc, libz, librt, libpthreads a další, které by byly načteny tak jako tak nějakým jiným procesem.

co prosím?

bavil ses snad o tom, co zabírá systemd ... to jako že když vezmu do auta stopaře, tak budu mít jako řidič tu cestu zadarmo?

Letmo jsem to skouknul, a myslím, že bychom se dostali na nějakých 4 až 10 MB, což imho vůbec není špatné porovnání...

tož když použijeme metodu poměřování penisů jak zkoušíte s kolegou výše přes RSS:

# ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
 49944  2684  6592

# ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
  4236   308    80

jasně, 82,4krát tolik vůbec není špatné porovnání

[kralyk z abclinuxu]

vidíš mezi nimi nějaký principiální rozdíl co se týče možností větvení kódu?

To je otázka, co by všechno ta tebou navržená syntaxe dovolovala. Pokud by dovolovala zanořování podmínek anebo třeba jánevim cykly, tak už by to možnosti byly výrazně volnější. Pokud by nic navíc nedovolovala (pouze tu jednu podmínku), tak to co do možností větvení pochopitelně vyjde nastejno, ale osobně preferuju to druhé, protože to nedělá z unitu skript. To je celý, nic víc na tom nehledám.

vidím tam ekvivalentní tvrzení, je-li načtený kdykoli se může zavolat start sshd ...

Tak to tam teda vidíš výrazně víc, než co tam je. Upřímně řečeno, nevím do detailu, jak tohle systemd řeší, ale 1) načíst service file nejspíš nebude nijak náročné a 2) paměťová náročnost systemd mi přijde ok, ať už si ty soubory načítá jakkoli...

co prosím? bavil ses snad o tom, co zabírá systemd

Přesně tak, zajímal mě systemd, nikoli systemd + libc + pthreads +... atd. Na systému se sysvinitem by totiž libc + pthreads +... zabraly úplně stejně jako se systemd, tudíž nás to nezajímá.

bavil ses snad o tom, co zabírá systemd ... to jako že když vezmu do auta stopaře, tak budu mít jako řidič tu cestu zadarmo?

Prosil bych se úplně vyvarovat automobilových přirovnání. Zaprvé absolutně netuším, cos tím chtěl říct (čímž nežádám o vysvětlení) a zadruhé by automobilovými přirovnáními absurdita diskuse stoupla nad práh fyzické bolesti

jasně, 82,4krát tolik vůbec není špatné porovnání

Je zajímavé, jak ses od absolutních jednotek přesunul k násobkům Ty budeš asi ten člověk z tohohle komixu (ten bez klobouku).

Na okraj: je trochu divný, že tam má init rss menší než size, možná je ten proces částečně odswapovaný, nevím. Každopádně, tady jde spíš o ten systemd, který evidentně moc velkou spotřebu nemá (zejména na mém systému), takže u mě case closed.

[kavol]

vidíš mezi nimi nějaký principiální rozdíl co se týče možností větvení kódu?

To je otázka, co by všechno ta tebou navržená syntaxe dovolovala.

to samý, co dovoluje aktuální, ale ne na úrovni celý unity nýbrž jednotlivejch položek

... ale osobně preferuju to druhé, protože to nedělá z unitu skript. To je celý, nic víc na tom nehledám.

vskutku nevidím, co je na tom "skriptovatějšího" než na současném řešení

Tak to tam teda vidíš výrazně víc, než co tam je.

aha, takže chceš říct, že informační obsah té věty je nula, abys nemusel přiznat rozpor s tím, co jsi napsal později?

Upřímně řečeno, nevím do detailu, jak tohle systemd řeší, ale 1) načíst service file nejspíš nebude nijak náročné

což je ovšem zase úplně jiné tvrzení, než to, že to už stejně bude načtené ...

a 2) paměťová náročnost systemd mi přijde ok, ať už si ty soubory načítá jakkoli...

no, a to je věc, na které se neshodneme ... to byl jeden z mých důvodů úniku pryč ze světa windows, nemuset každý rok kupovat nový hardware, jen abych mohl používat aktuální (ve smyslu záplatovaný, ne hypersupermegacoolin) software ...

co prosím? bavil ses snad o tom, co zabírá systemd

Přesně tak, zajímal mě systemd, nikoli systemd + libc + pthreads +... atd.

wtf, a on ten systemd bez uvedeného může běžet?

Na systému se sysvinitem by totiž libc + pthreads +... zabraly úplně stejně jako se systemd, tudíž nás to nezajímá.

jak můžeš napsat "úplně stejně", když jsem ti výše dal konkrétní příklad, kde je spotřeba o řád menší?

proč bych měl řešit spotřebu něčeho, co vůbec nepotřebuju? budu-li mít systém s busyboxem nad uclibc, například, nač bych si tam měl od init systému nechat tahat glibc?

bavil ses snad o tom, co zabírá systemd ... to jako že když vezmu do auta stopaře, tak budu mít jako řidič tu cestu zadarmo?

Prosil bych se úplně vyvarovat automobilových přirovnání. Zaprvé absolutně netuším, cos tím chtěl říct (čímž nežádám o vysvětlení)

no, já jsem se chtěl dopátrat toho, co tím míníš ty ...

a zadruhé by automobilovými přirovnáními absurdita diskuse stoupla nad práh fyzické bolesti

"absurdita diskuse"? - no, kam jsi to dovedl, tam to máš, viz:

jasně, 82,4krát tolik vůbec není špatné porovnání

Je zajímavé, jak ses od absolutních jednotek přesunul k násobkům

jen jsem pro náhodné čtenáře vypíchnul tu absurditu, že pro tebe je 6,5 MB stejně zanedbatelných jako 80 KB ...

Na okraj: je trochu divný, že tam má init rss menší než size, možná je ten proces částečně odswapovaný, nevím.

co je na tom divnýho? - výhoda jednoduchýho initu, viz výše kolega trekker.dk o kešování ...

Každopádně, tady jde spíš o ten systemd, který evidentně moc velkou spotřebu nemá (zejména na mém systému), takže u mě case closed.

oukej, mám ti poslat číslo konta abych si to koupil sám nebo raději fyzickou adresu, kam mi pošleš pár DDR3?

[kralyk z abclinuxu]

vskutku nevidím, co je na tom "skriptovatějšího" než na současném řešení

Ten branch je na úrovni deklarativních jednotek, ne někde uprostřed kódu. Ale pochybuju, že bys tohle odůvodnění akceptoval, takže tohle asi budem muset prostě uzavřít s tím, že se neshodnem...

aha, takže chceš říct, že informační obsah té věty je nula, abys nemusel přiznat rozpor s tím, co jsi napsal později?

Cože? Obsahem té věty bylo, že systemd pravděpodobně (podle mě) načítá unity, které jsou závislostí (že se následně v té unitě nic neprovede, je jiná věc). Jak to souvisí s dobou, po kterou systemd drží načtené units v paměti, mi opravdu uniká.

proč bych měl řešit spotřebu něčeho, co vůbec nepotřebuju? budu-li mít systém s busyboxem nad uclibc, například, nač bych si tam měl od init systému nechat tahat glibc?

Jsem přesně čekal, že začneš argumentovat specializovanám systémem To sis ale mohl ušetřit tu práci - na takhle/podobně specializovaným systému bych ani já systemd nejspíš nedoporučil, resp. záleželo by na požadavcích a dalších okolnostech.

Kažopádně kontext zprávičky je celkem jasný: Ubuntu, resp. desktop linux.

jen jsem pro náhodné čtenáře vypíchnul tu absurditu, že pro tebe je 6,5 MB stejně zanedbatelných jako 80 KB ...

Na mém systému systemd zabírá necelé 2MB, což je pro mě v kontextu linux desktopu stejně zanedbatelné jako jakákoli jiná hodnota menší než 2MB. Nic absurdního na tom nevidim. 6,5 MB už je o něco víc, ale pravděpodobně bych to taky neřešil.

oukej, mám ti poslat číslo konta abych si to koupil sám nebo raději fyzickou adresu, kam mi pošleš pár DDR3?

Pošli mi číslo konta. Až si budeš příště kupovat DDR3 modul, tak ti zaplatím část, kterou zabere systemd, což bude asi 0,3 ~ 2 Kč, podle OS a ceny modulu.

[kavol]

vskutku nevidím, co je na tom "skriptovatějšího" než na současném řešení

Ten branch je na úrovni deklarativních jednotek, ne někde uprostřed kódu. Ale pochybuju, že bys tohle odůvodnění akceptoval, takže tohle asi budem muset prostě uzavřít s tím, že se neshodnem...

no, asi neshodnem, neb by nebyl "uprostřed kódu" ale "uprostřed konfigurace"

aha, takže chceš říct, že informační obsah té věty je nula, abys nemusel přiznat rozpor s tím, co jsi napsal později?

Cože? Obsahem té věty bylo, že systemd pravděpodobně (podle mě) načítá unity, které jsou závislostí (že se následně v té unitě nic neprovede, je jiná věc). Jak to souvisí s dobou, po kterou systemd drží načtené units v paměti, mi opravdu uniká.

souvisí to tak, že to je drženo v paměti až do okamžiku, u kterého ses vyjádřil "který už stejně pravděpodobně je načtený" - aby to už bylo načteno, musí to být v paměti

nebude-li to v paměti, nelze o tom říci, že už to tam je (= je načteno)

přijde ti lepší hrát úplně blbýho, že nechápeš takovouto jednoduchou konstrukci, nežli přiznat, žes udělat v úvahách nějakou chybku a skutečně sis zpochybnil vlastní tvrzení?

proč bych měl řešit spotřebu něčeho, co vůbec nepotřebuju? budu-li mít systém s busyboxem nad uclibc, například, nač bych si tam měl od init systému nechat tahat glibc?

Jsem přesně čekal, že začneš argumentovat specializovanám systémem To sis ale mohl ušetřit tu práci - na takhle/podobně specializovaným systému bych ani já systemd nejspíš nedoporučil, resp. záleželo by na požadavcích a dalších okolnostech.

ano, jako obvykle, co se nám nehodí do krámu, to budeme ostentativně ignorovat ... mohl já jsem od tebe čekat něco jiného?

Kažopádně kontext zprávičky je celkem jasný: Ubuntu, resp. desktop linux.

ten desktop sis vycucal kde? Ubuntu neběží na servech, nesnaží se o nějaké vlastní telefony?

jen jsem pro náhodné čtenáře vypíchnul tu absurditu, že pro tebe je 6,5 MB stejně zanedbatelných jako 80 KB ...

Na mém systému systemd zabírá necelé 2MB, což je pro mě v kontextu linux desktopu stejně zanedbatelné jako jakákoli jiná hodnota menší než 2MB. Nic absurdního na tom nevidim. 6,5 MB už je o něco víc, ale pravděpodobně bych to taky neřešil.

viz výše, ten kontext "desktop" sis tam domyslel sám

systemd se například cpe do virtualizace, kde se řeší minimalistické virtuálky, jak prý s ním krásně rychle bootují, a jak je to super, když je potřeba jich pouštět dynamicky velké počty - takže třeba 1000*6,5 MB = 6,5 GB, no, to už se na serveru taky pozná (nejsem si jist, jak moc dobře lze dělat deduplikaci zrovna tohoto kusu alokované paměti)

oukej, mám ti poslat číslo konta abych si to koupil sám nebo raději fyzickou adresu, kam mi pošleš pár DDR3?

Pošli mi číslo konta. Až si budeš příště kupovat DDR3 modul, tak ti zaplatím část, kterou zabere systemd, což bude asi 0,3 ~ 2 Kč, podle OS a ceny modulu.

a ono se dá dokoupit jenom 6,5 MB samostatně? - a mimochodem, taky mi na tom běží nějaké virtuálky ...

no ale je to hezké, k čemu jsme se to tu dobrali ... takže tady vidíme, že krom různých jiných důsledků působí systemd zjevnou ekonomickou škodu ve výše uvedené výši na jednu instanci - kolik že má linux uživatelů, kolik že na tom běží serverů atd.? - měli bysme navrhnout úniji, ať kromě žárovek zakáže taky Lennarta, to by byly úspory

[kralyk z abclinuxu]

souvisí to tak, že to je drženo v paměti až do okamžiku, u kterého ses vyjádřil "který už stejně pravděpodobně je načtený" - aby to už bylo načteno, musí to být v paměti

No protože je dependencí. Nicméně i kdyby byl načtený nějak automaticky už od spuštění systemd nebo od kdy (což je zřejmě to, co se snažíš z toho mého výroku vytáhnout), tak to stále nijak nesouvisí s otázkou, jestli bude v paměti hnít až do konce běhu systému, protože to tak vůbec nemusí být.

ano, jako obvykle, co se nám nehodí do krámu, to budeme ostentativně ignorovat ... mohl já jsem od tebe čekat něco jiného?

Cože? Já přece nic neignoroval.

ten desktop sis vycucal kde? Ubuntu neběží na servech, nesnaží se o nějaké vlastní telefony?

Na serverech nevidím problém s 6MB RAM na init. Telefony mají dnes minimálně 1GB RAM a pamětí plítvají na kde co...

systemd se například cpe do virtualizace, kde se řeší minimalistické virtuálky, jak prý s ním krásně rychle bootují, a jak je to super, když je potřeba jich pouštět dynamicky velké počty - takže třeba 1000*6,5 MB = 6,5 GB, no, to už se na serveru taky pozná (nejsem si jist, jak moc dobře lze dělat deduplikaci zrovna tohoto kusu alokované paměti)

Aha, takže tím jsi ukázal, že když malé číslo vynásobíme číslem 1000, je z toho velké číslo. Wow. Bez údaje, kolik ty virtuály zabírají celkem a jestli se to dá deduplikovat je nám to číslo celkem k prdu. Jinak ale, jak už jsem řekl ve #229, mě nějaké hypotetické systémy / hypotetické situace nezajímají, protože se dá vždycky vymyslet hypotetická situace čistě na míru tak, aby z toho systemd vyšlo špatně. Až budeš mít reálné údaje, dej vědět...

[kralyk z abclinuxu]

a? já jsem řekl, že se spustí ten soubor? nebo celou dobu mluvím o službě?

Ani žádná služba se nespustí. Kde tam něco takovýho vidíš? To jako že se tam před kontrolou existence souborů spustí třeba httpd nebo mysqld?

bavím se o tom, co udělá před tím "nic"

Máš to tam jasně napsaný - před tím "nic" zkontroluje existenci souborů, což dělá samotný systemd při řešení závislostí sshd.service, nic dalšího kvůli tomu nespouští.

a teď ještě prosím vysvětlení, jak tyto řádky souvisí s tou částí problému startu sshd, o které se tu bavíme, tedy (ne)vytvářením klíčů?

Stěžoval sis, že ten service nešetří spouštěním procesů oproti skriptu. Snažil jsem se naszačit, že to není pravda (ať už se bavíme o kterékoli verzi service - oboje jsou šteřivější než ten skript).

notabene když ten skript je určitým způsobem zprasený?

Jasně, že je sprasený - vždyť je to init skript

haú ... mluvil jsem jasně o dvou variantách, "aktuální řešení" a "řešení o kterém se bavíme, tedy formou závislosti", řekl jsem jasně, že druhé je jiné než prvé, a přesto sis neráčil všimnout, že to není jedno a totéž, a pod prvé mi cpeš reakci nad druhé? seš zfetovanej?

Uklidni se, nic nefetuju, mně akorát nebylo jasný, který je to "aktuální". Díky za objasnění. Ano v tom "atkuálním" se spouští bash. Jeden fork navíc (za předpokladu, že ten skript už se neforkuje). To mi nepřijde tak hrozný, navíc to zřejmě bude fixnuto tím "řešením, o kterém se bavíme".

[kavol]

a? já jsem řekl, že se spustí ten soubor? nebo celou dobu mluvím o službě?

Ani žádná služba se nespustí. Kde tam něco takovýho vidíš? To jako že se tam před kontrolou existence souborů spustí třeba httpd nebo mysqld?

sám jsi to napsal: "Samozřejmě, že ta závislost není podmíněná, na službě sshd-keygen to závisí vždy."

Máš to tam jasně napsaný - před tím "nic" zkontroluje existenci souborů, což dělá samotný systemd při řešení závislostí sshd.service, nic dalšího kvůli tomu nespouští.

to právě není pravda, ty soubory nekontroluje při řešení závislostí ale až potom - ostatně teď jsem ocitoval tvůj vlastní výrok, kde připouštíš, že sshd-keygen se "zpracuje"(*) vždy

(*) když se nelíbí výraz "spustí", i když tedy v kontextu závislostí služeb se to používalo vždy, a až do této diskuse jsem si jaksi nevšiml, že by zrovna na této terminologii systemd něco měnil

a teď ještě prosím vysvětlení, jak tyto řádky souvisí s tou částí problému startu sshd, o které se tu bavíme, tedy (ne)vytvářením klíčů?

Stěžoval sis, že ten service nešetří spouštěním procesů oproti skriptu. Snažil jsem se naszačit, že to není pravda (ať už se bavíme o kterékoli verzi service - oboje jsou šteřivější než ten skript).

kontext prosím, kontext ... bavím se o generování klíčů, ne o celém skriptu

kromě toho, ta původní poznámka se vůbec netýkala porovnání, nýbrž toho, že se nešetří volání bashe tam, kde by se šetřit mohlo, ačkoli se tím autoři systemd holedbali (a ano, uznávám, že tato konkrétní implementace není chybou systemd samotného, ostatně v následujícím komentáři jsem zdůrazňoval, že jsem v tu chvíli nevěděl, co v tomto směru samotný systemd umí nebo neumí, nicméně jaksi to dává jistý nádech absurdity prohlášením o tom, jak deklarativní zápis napomůže proti prasárnám )

Ano v tom "atkuálním" se spouští bash. Jeden fork navíc (za předpokladu, že ten skript už se neforkuje). To mi nepřijde tak hrozný,

tak "hrozný" to samozřejmě není, ostatně mně nepřijde nic hroznýho ani na celým initu postaveným na skriptech, ale v dané situaci je to IMO prostě zbytečný, absurdní

navíc to zřejmě bude fixnuto tím "řešením, o kterém se bavíme".

puštění bashe, když není potřeba, ano, ale pořád tam poběží kód, který by běžet nemusel, kdyby se ta podmínka vyhodnotila dříve, zesložiťuje se to o další službu

[kralyk z abclinuxu]

a ano, uznávám, že tato konkrétní implementace není chybou systemd samotného, ostatně v následujícím komentáři jsem zdůrazňoval, že jsem v tu chvíli nevěděl, co v tomto směru samotný systemd umí nebo neumí, nicméně jaksi to dává jistý nádech absurdity prohlášením o tom, jak deklarativní zápis napomůže proti prasárnám

Možná tě to šokuje, ale přechod na systemd byl dost postupný, spouštění skriptů bylo zejména ze začátku dost běžné. Každopádně to bylo fixnuto, takže teď už asi celkem není co řešit.

puštění bashe, když není potřeba, ano, ale pořád tam poběží kód, který by běžet nemusel, kdyby se ta podmínka vyhodnotila dříve, zesložiťuje se to o další službu

Ale vždyť je to v podstatě no-op. Ta režije toho dalšího unitu je naprosto minimální.

Já fakt nechápu, o co ti jde. Co se výkonu týče, v init skriptech u tebe projde prakticky cokoli, zatímco u systemd je najednou hroznej problém, když se něco rozdělí do dvou souborů s režií +0.001%... V init skriptech snad nebyly nikdy věci rozděleny do více souborů?

No jo, kdo chce psa bít...

[kralyk z abclinuxu]

viz výše, bude to mít větší režii než ta část skriptu, která řeší problém klíčů

Teď jsem si všiml, že tohle není pravda - funkce do_rsa1_keygen() v prvním ifu forkuje.

[kavol]

to `fips_enabled`? - hm, máš pravdu, to jsem si taky nevšimnul těch backticks (jak se to kua řekne česky?), kdo by taky čekal volání funkce takovýmto způsobem ... ovšem ... jakým způsobem se to vyhodnocuje, při nesplnění první podmínky by už neměl řešit druhou, ne? - navíc ta druhá v systemd ani nejde definovat (pokud dobře čtu dokumentaci k Condition*), takže těžko lze v tomto případě srovnávat efektivitu

[pavlix]

zatímco původní skript volá generování klíčů jen když neexistují, systemd verze to volá při každém startu služby

Ve skutečnosti systemd volá původní skript. A jako bonus systemd umí zavolání podmínit neexistencí klíčů. Tím pádem v případě existence klíčů skutečně šetří spouštěním procesů a na ten bashovský skript vůbec nepůjde.

Jakkoliv systemd nemáš rád, je dobré argumentovat fakty a ne úplnými nesmysly.

[pavlix]

Ve skutečnosti systemd volá původní skript.

Abych to upřesnil, systemd na základě .service volá distribuovaný skript, který projde všechny klíče, které mají být vygenerované a vygeneruje chybějící. Navíc jsem teď ověřil, že ssh-keygen -A dělá to samé, až na to, že ještě kontroluje FIPS mód, aby generoval jenom některé z klíčů, hraje si se selinuxem a podobné sračky.

Odpovídající kód v Gentoo zde:

checkconfig() {
        if [ ! -d /var/empty ] ; then
                mkdir -p /var/empty || return 1
        fi

        if [ ! -e "${SSHD_CONFDIR}"/sshd_config ] ; then
                eerror "You need an ${SSHD_CONFDIR}/sshd_config file to run sshd"
                eerror "There is a sample file in /usr/share/doc/openssh"
                return 1
        fi

        ssh-keygen -A || return 1

        [ "${SSHD_PIDFILE}" != "/var/run/sshd.pid" ] \
                && SSHD_OPTS="${SSHD_OPTS} -o PidFile=${SSHD_PIDFILE}"
        [ "${SSHD_CONFDIR}" != "/etc/ssh" ] \
                && SSHD_OPTS="${SSHD_OPTS} -f ${SSHD_CONFDIR}/sshd_config"

        "${SSHD_BINARY}" -t ${SSHD_OPTS} || return 1
}

[kavol]

zatímco původní skript volá generování klíčů jen když neexistují, systemd verze to volá při každém startu služby

Ve skutečnosti systemd volá původní skript.

asi by bylo dobré ujasnit si, co je "původní skript"

já měl na mysli to co kolega citoval o notný kus výše

ty teď zřejmě mluvíš pouze o jeho části vytažené do souboru /usr/sbin/sshd-keygen

rozdíl je, že v tom initskriptu je ta rozhodovací logika v rámci jednoho procesu, zatímco se systemd se spustí další proces jen proto, aby nic neudělal a zase skončil

A jako bonus systemd umí zavolání podmínit neexistencí klíčů.

možná umí, ale v citovaném kódu nedělá - viz odpověď Michalovi

Tím pádem v případě existence klíčů skutečně šetří spouštěním procesů a na ten bashovský skript vůbec nepůjde.

nepsal jsi náhodou, že se to uplatní jen při socket activation?

(ok, takže jsem výše udělal chybku, když jsem řekl "každém" bez upřesnění, že myslím klasický start)

Jakkoliv systemd nemáš rád, je dobré argumentovat fakty a ne úplnými nesmysly.

taky bývá dobré, když něco označíš za nesmysly, nějak to doložit, co konkrétně a proč by měl být nesmysl ...

[pavlix]

nepsal jsi náhodou, že se to uplatní jen při socket activation?

Ano, to platí pro ten zkoumaný fedoří SSH balíček, protože ho tak někdo napsal. Nejedná se o limitaci systemd. To by snad mělo vše vysvětlovat.

[pavlix]

Založil jsem na to ticket na rawhide.

[pavlix]

Ticket na Gentoo.

[pavlix]

A takto to vypadá v OpenSUSE.

sshd.service:

[Service]
EnvironmentFile=-/etc/sysconfig/ssh
ExecStartPre=/usr/sbin/sshd-gen-keys-start
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

sshd-gen-keys-start:

#!/bin/sh
if ! grep -q '^[[:space:]]*HostKey[[:space:]]' /etc/ssh/sshd_config; then
    echo "Checking for missing server keys in /etc/ssh"
    ssh-keygen -A
fi

Ten skript je podle všeho úplně zbytečný. Kromě ssh-keygen -A volá jen nějakou pochybnou podmínku, která by se u samostatné služby dala dát do ExecStartPre, pokud by se použil samostatný sshd-keygen.service a následně by jim to pomohlo, kdyby chtěli podporovat sshd.socket.

[kavol]

pěkné, ábíčko je teď naše nová vývojářská platforma?

ok, takže se nám režie se spuštěním bashe mění na režii s přidáním prvku do stromu závislostí (což mi nepřijde úplně user friendly) a spuštěním služby (která bude asi významně menší, ale stále nenulová)

hm ... tady v tom konkrétním případě tedy vidím přínos systemd poněkud záporně :-p

[pavlix]

Já tu nejsem od toho, abych přesvědčil jednu nebo druhou stranu, to už sis snad mohl všimnout. Ale jsem rád, že jsem ti pomohl pochopit alespoň fakta. Výsledný názor už je každého věc.

[kavol]

já myslím, že o faktech nebylo sporu od začátku, jediné, co jsem si v dalším průběhu diskuse ujasnil, bylo to podmiňování unit, a v tom jste mi tu nepomohl nikdo, ale man ... problém byl spíše v učiněných závěrech, kde jisté neshody mohly vést k dojmu, že vycházím ze špatných předpokladů (mé občasné nevyřčení podmínek tomu jistě neprospělo, omlouvám se)

co se týče výsledného názoru, k tomu asi nemám již co více říci než jsem teď napsal kralykovi v poslední větě - snad jen doplnit že (pro uživatele velký) problém podobného ražení je například také s inicializací databází, rozhodně nejde jen o nějaký vyjímečný případ sshd

[pavlix]

Nevím, čemu říkáš inicializační databáze, ale jestli je její problém stejný jako u sshd, tak jsme za vodou.

[Honza Jaroš]

inicializační != inicializací

[pavlix]

Aha. Faktem je, že bych doporučil stejné řešení jako u SSH. Alespoň půjde sledovat průběh a při rozumných nástrojích může administátor vědět, na čem jeho databázová služba v tu chvíli visí.

[Heron]

problém podobného ražení je například také s inicializací databází, rozhodně nejde jen o nějaký vyjímečný případ sshd

A zajímavé je, že u postgresql je nutné zavolat service postgresql initdb, tak u ssh se podobná operace provede sama během startu. Není to úplně konzistentní.

[pavlix]

Tož konzistentní to rozhodně není. Ale pravda je, že databázové systémy a podobné jednoúčelové služby nemají zrovna historii konzistence se zbytkem systém. Postgres není konzistentní ani v mnoha dalších věcech jako třeba FHS.

[kavol]

ovšem zase je to ssh konzistentní s mysql

[pavlix]

Měl bysis alespoň pečlivě přečíst, na co odpovídáš. Tím shrnutím včetně ukázek jsem strávil tolik času, že kdybys přečtení věnoval setinu toho času, tak bys tuhle odpověď nemohl napsat, a musím říct, že mě mrzí, že jsi tomu nedal ani to.

[kavol]

ach, jak věcné ...

[coques]

U mňa vyhráva Upstart, proste krásny prehľadný skript ;)

[kralyk z abclinuxu]

RestartSec=42

Hezké... Zatím asi musela být úvaha "v případě selhání počkáme 42 sekund, on se mezitím vesmír uklidní"

[j]

lol .. presne na tohle staci tak max 10(hodne kratkych) radku. Restartovat neco kdyz to zbuchlo je zcela zasadne spatne. K tomu zbuchnuti byl nejspis nejaky duvod a restartovanim se to muze tak maximalne dojebat.

Nehlede na to, fakt chci videt, jak svymu uzasnymu supervisorovi reknes, ze chces neco nastartovat za uplnku, v pripadne ze je mars v opozici s venusi ... a venkovni teplota neprekracuje -30 ... coz se vpohode do initu napsat da.

[Michal Vyskočil]

Na to první potřebuješ cca 150řádkový init script a ještě jednou tolik na správnou démonizaci procesu.

Anebo můžeš použít skutečné Unixové™ řešení a do /etc/inittab napsat něco jako

foo:2345:respawn:/opt/bin/beepd

a neřešit novoty jako init skripty, démonizaci, nebo dokonce System V Unix . Akorát pak člověk zjistí, že ač je /sbin/init docela schopný supervizor, formát inittabu je tak omezený, že se jeho vlastnosti prakticky nedají použít.

[Heron]

Na to první potřebuješ cca 150řádkový init script a ještě jednou tolik na správnou démonizaci procesu.

To má být vtip?

[kavol]

asi jo ...

schválně jsem se teď podíval na skriptík, kterým si manažuju (fujslovo) virtuálku, a má 56 řádků včetně komentářů, a spousty omáčky, které bych se mohl zbavit, kdybych použil nějaké hotové řešení ala virt-manager a nedělal si věci po svém (a těch řádek by byla polovina, kdybych se nesnažil formátovat to, aby to bylo přehledné)

ekvivalentní service unitu bych nebyl schopen napsat, jelikož systemctl chybí mezi unit commands akce "reboot" (neplést s reboot ze system commands), protože Lennart řekl, že služby smí dělat jenom to, co on povolí, a nikoli to, co admin potřebuje ...

[pavlix]

ekvivalentní service unitu bych nebyl schopen napsat, jelikož systemctl chybí mezi unit commands akce "reboot" (neplést s reboot ze system commands), protože Lennart řekl, že služby smí dělat jenom to, co on povolí, a nikoli to, co admin potřebuje ...

No já jsem teď seděl v Brně s Lennartem a dalšími na té debatě o systemd ve Fedoře. Řešily se tam přesně takovéhle věci. Někdo chtěl rozlišovat reload konfigurace a reexec služby, přičemž to druhé se dělá u některých nástrojů za účelem spuštění nové verze z právě nainstalovaného update. Ten reexec má fungovat tak, že starý proces předá novému procesu data (ať už přes IPC nebo je prostě na chvíli odloží do FS) a spustí nový proces. Lennart rozhodl, že se to musí nutně řešit voláním exec a odložením dat do FS, s čímž bych i docela souhlasil. Dále rozhodl, že čistý reload nikdo nepotřebuje, takže se to bude jmenovat dál reload, ale služby, které to umějí, ať si tam dělají reexec, s tím, že to sloučí i pro systemd samotné, kde je to podle všeho nyní rozlišené.

[kavol]

nějak mi unikla pointa a souvislost s mým příspěvkem, tedy kromě toho, že zase bude hafo lidí mít hafo práce s ohackováním corner(???) casů, protože "Lennart rozhodl" ...?

[pavlix]

kromě toho, že zase bude hafo lidí mít hafo práce s ohackováním corner(???) casů, protože "Lennart rozhodl" ...?

A to ti nestačí? :)

[kavol]

no, já si nebyl jistý, jak to brát

[pta]

Nejaky cas to nesleduju, ale vim ze byl problem s nepodporou spousteni sluzeb ktere pak nejsou svazane s bezicim procesem/(y v cgroups) a potazmo socketem jako treba konfigurace firewallu nebo jednorazovy skript (udrzba, rsync, …). Zmenilo se od ty doby neco ?

Btw. ta sprava sluzeb (demoni uz asi pomreli) s jejich automatickym restartovanim mi hodne pripomina zkusenost s adminovanim Win2k server a pozdejsich. Reseni problemu zpusobem povolim 5x restart a pokud to spadne po 6 tak uz asi bude problem, je pro me navrat do obskurniho sveta servirovaneho z Redmondu, od ktereho jsem tak rad utekl k *nixum. Asi mi nekdo nevymluvi, kde hledali vyvojari systemd inspiraci.

[pavlix]

Nejaky cas to nesleduju, ale vim ze byl problem s nepodporou spousteni sluzeb ktere pak nejsou svazane s bezicim procesem/(y v cgroups) a potazmo socketem jako treba konfigurace firewallu nebo jednorazovy skript (udrzba, rsync, …). Zmenilo se od ty doby neco ?

Nesledoval jsem historii, ale oneshot služby jsou pokud vím podporované a hojně využívané.

navrat do obskurniho sveta servirovaneho z Redmondu, od ktereho jsem tak rad utekl k *nixum. Asi mi nekdo nevymluvi, kde hledali vyvojari systemd inspiraci.

Pokud vím, tak veřejně přiznali inspiraci u Applu. Nicméně, pokud se ti systemd nelíbí, nevidím problém používat open source distribuci, která se bez něj obejde a podílet se na její údržbě a jejím vývoji.

[pta]

Nesledoval jsem historii, ale oneshot služby jsou pokud vím podporované a hojně využívané.

Dik, uz jsem k tomu nasel i dokumentaci.

System service Type= simple, forking, oneshot, dbus, notify or idle.

Omezena mnozina voleb - to je bohuzel presna demonstrace opacneho(inflexibilniho) pristupu k reseni problemu.

Pokud by se systemd osvojil dobrovolne, asimilace by probehla evoluci, tak by se proti tomu dalo jen tezko neco namitat. Bohuzel je ale prosazovan z pozice sily a to za nic pozitivniho nepovazuju. Your mileage may vary.

Pokud vím, tak veřejně přiznali inspiraci u Applu. Nicméně, pokud se ti systemd nelíbí, nevidím problém používat open source distribuci, která se bez něj obejde a podílet se na její údržbě a jejím vývoji.

To by mohlo odpovidat. Pokud si dobre pamatuju tak v nejakem rozhovoru k PA mluvil taky o inspiraci u Applu a jejich Core audio.

Ja se vedle svoji prace zmuzu maximalne na zasilani bugfixu. Rozsahlejsi veci jsem delal taky, ale pro projekty z uplne jiny oblasti (hlavne e-commerce). My zatim jedeme na systemech ktere jeste bezi na SysV initu, ale az skonci podpora tak se prechodu zrejme nevyhneme. Z retestingu a noveho zauditovani spousty na zakazku psanych skriptu mi sedivi vlasy uz ted. Trochu si pripadam jak ve virtualni realite, kdy nam na rozsahlych a docela divokych konfiguracich vsechno slape a pritom na netu ctu o tom jak je "stary" init polofunkcni, nespolehlivy a buhvi co jeste a mel byt nahrazen systemd uz vcera.

Budu fandit OpenRC u Gentoo, Slackware se SysV init/BSD rc-skripty, ale bude to jak boj Davida s Goliasem. Jestli vyznamne projekty z upstreamu zavedou nevolitelne zavislosti na systemd (x jich financuje RH), tak to bude hodne tezky. Bohuzel nemam kapacitu jim vyvojem pomahat.

[pavlix]

Ja se vedle svoji prace zmuzu maximalne na zasilani bugfixu.

A o tom přesně open source je. Člověk může určovat (alespoň alternativní) směry vývoje, pokud si na to dokáže najít čas a pokud mu na tom záleží. V opačném případě mu nezbývá než se smířit s tím, co na trhu je. To je rozdíl mezi open source vývojářem a konzumentem. Reportování bugů a příležitostné zasílání patchů je zásadní pomoc, o tom žádná, ale víceméně v rámci toho směru, který ti tvoji vývojáři zvolí.

Trochu si pripadam jak ve virtualni realite, kdy nam na rozsahlych a docela divokych konfiguracich vsechno slape a pritom na netu ctu o tom jak je "stary" init polofunkcni, nespolehlivy a buhvi co jeste a mel byt nahrazen systemd uz vcera.

Tradiční kontroverze mezi produkcí a vývojem ;).

Budu fandit OpenRC u Gentoo

Gentoo už má systemd jako alternativu a některé balíky ho přímo vyžadují, třeba zrovna Gnome. To znamená odliv části uživatelů a vývojářů od OpenRC, což může mít zpětnou vazbu a způsobit odliv dalších a odstavení OpenRC na vedlejší kolej či jeho úplně opuštění.

[pta]

Pokud jde k ledu i OpenRC, tak jak by mela podpora alternativ(y) vypadat ? Patche k upstramu, aby sel zkompilovat bez systemd ? To vidim jako dlouhodobe neudrzitelne.

[kavol]

Patche k upstramu, aby sel zkompilovat bez systemd ? To vidim jako dlouhodobe neudrzitelne.

... notabene když o to upstream nemá zájem

[Foo Bar]

Olav (release manager Gnome) vyzýval komunitu k podpoře non-systemd konfigurací už před rokem a půl. Doteď se mu nikdo neozval. Tak asi tak.

[...]

a gnome bere jeste nekdo vazne?

[pavlix]

To je ten, co vykřikuje, že Gnome poslouchá své uživatele a dokazuje to tím, že tlačítko suspend změnili na tlačítko shutdown, když komunita volala po původní nabídce s možností volby? Ten člověk působí jak šílený markeťák, není divu, že ho nikdo neposlouchá.

[mkmm]

Do toho se nikomu nechce, ale jde to. Treba v OpenBSD je Gnome 3.

[Michal Vyskočil]

Gentoo už má systemd jako alternativu a některé balíky ho přímo vyžadují, třeba zrovna Gnome. To znamená odliv části uživatelů a vývojářů od OpenRC, což může mít zpětnou vazbu a způsobit odliv dalších a odstavení OpenRC na vedlejší kolej či jeho úplně opuštění.

Co dohackovat do openrc podporu pro čtení systemd units? Ta filozofie obou zase není tak odlišná a systemd podporuje prefix x- pro volby, které má ignorovat, takže by nemělo být tak složité používat jednu unitu pro oboje.

[mkmm]

Ty rc skripty ve Slackware mozna take nevydrzi. Patrick v jednom lonskem rozhovoru rekl, ze se inovacim nebrani a az bude systemd funkcni a vyzraly, mohl by se pouzit. Osobne doufam, ze to bude jeste dlouha doba.

[Pavel]

Diky za upozorneni. Dalsi distribuce ktere se radsi z dlouhodobyho hlediska vyhnout. Mel sem to jako kandidata (precejenom obcas clovek ten linux potrebuje)...

[...]

tak to je FUD a never tomu a najdi si original. rekl to docista jinak.

but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle.

[David Jaša]

Dik, uz jsem k tomu nasel i dokumentaci.

System service Type= simple, forking, oneshot, dbus, notify or idle.

Omezena mnozina voleb - to je bohuzel presna demonstrace opacneho(inflexibilniho) pristupu k reseni problemu.

Lennartův přístup (resp. dnes už přístu projektu systemd) mi v tomhle ohledu úplně blbej nepřijde. Lennart se sice tváří, že jeho množina akcí a konfigurací je konečná a do systemd nikdy nic nepřibude, ale zrovna třeba ty oneshot služby ukazují, že pokud je o nějakou _konkrétní_ věc zájem, nakonec se do systemd dostane. Dlouhodobě tak může konfigurační/akční schéma systemd obsáhnout prakticky všechny potřeby správy služeb, závislostí atd., něco, čeho by se nedalo dosáhnout, pokud by byla možnost psát ošklivé záseky (ugly hacks ) při každé příležitosti, kdy je množina konfigurací a akcí nabízených systemd příliš slabá.

Toto by nakonec mohlo představovat i cestu jak systemd nahradit: právě proto, že je formát unit souborů vytesán do kamene a nejsou z něj žádné úniky do konfigurace jiným programem (čti shell skriptů), mělo by být možné celé schéma reimplementovat na zcela jiném základě. Vzhledem k historii jsem zvědavý, jestli se o něco podobného v nejbližších letech nepokusí FreeBSD.

[Michal Vyskočil]

. Vzhledem k historii jsem zvědavý, jestli se o něco podobného v nejbližších letech nepokusí FreeBSD.

https://wiki.freebsd.org/launchd, respektive openlaunchd

[David Jaša]

Měl jsem na mysli kompatibilní vrstvu - systemd api poskytované launchd jednak pro podporu systemd unit, druhak pro věci jako logind nebo per-session systemd.

[martin]

právě proto, že je formát unit souborů vytesán do kamene a nejsou z něj žádné úniky do konfigurace jiným programem (čti shell skriptů)

type=forking neni unikem k shell skriptum? (honest question)

[David Jaša]

nevím. Spíš jsem měl na mysli třeba odpor k přidání nějakého programovatelného zjišování informací pro status.

[Michal Vyskočil]

nevím. Spíš jsem měl na mysli třeba odpor k přidání nějakého programovatelného zjišování informací pro status.

On spíše neexistuje rozumný způsob to udělat rozumně a konzistentně se zbytkem systému. Momentálně je systemd zcela pasivní a notifikace o stavu mu zasílá jádro, nebo démon (Type=notify). Pokud by existoval ExecStatus, znamenalo by to

• příkaz systemctl by se v případě naivní implementace podobal spíše fork-bomb
• takže buďto je třeba všechny ExecStatus periodicky spouštět
• anebo akceptovat, že systemd bude o stavu těchto služeb kecat a nebude poskytovat signály o změně stavu

Nicméně z posledního Kayova prohlášení to nevypadalo, že by patche odmítali, spíše, že to nehodlají implementovat.

[pta]

Z jedne diskuse k systemd z roku 2012

Q. How many BSD devs does it take to change a light bulb?
A. Doesn't matter, the hardware's not supported!

Q. How many Gnome devs does it take to change a light bulb?
A. Doesn't matter, the last one to leave remembered to turn if off!!

Q. How many Lennart Poettering's does it take to change a light bulb?
A. Dunno, can't find the man page!!!

Q. How many Lennart Poettering's does it REALLY take to change a light bulb?
A. Light bulbs are old fashioned and no use to anyone, all who use them shall
   be crushed by the onward march of the NEW, IMPROVED, photon propagation
   "bulbd" which can only be changed by reading 18 documents, and requires
   a special bulbd reconfigurator !!!!

Q. How many "haters gonna hate"?
A. Me

Ah, my poor beloved UNIX, ruined by the "youth of today", with their utopian dreams of GUIs where I can't change where the clock goes, installers that can't be automated by a simple text file, or better, a world where whining cry babies ("haters gonna hate, waa, waa, I want my mommy"),seem to get more influence in distributions than that mean and oafish Linus fellow.