Zpátky na OpenRC

22.11.2016 00:17 | Přečteno: 2570× | linux/unix | | poslední úprava: 22.11.2016 00:25

Asi rok a půl používám Gentoo se systemd. Hlavní motivací bylo mít vývojové prostředí co nejbližší Fedoře kvůli vývoji a testování systémových služeb. Už delší dobu jsem do unit souborů služeb nemusel zasahovat a teď navíc zcela zásadně měním náplň práce.

Takže se dá říct, že nejzásadnější důvod pro provoz systemd pominul. Navíc jsem v poslední době narazil hned na několik bugů, jejichž analýza vedla k systemd. A v neposlední řadě se příležitostně věnuju projektu gentoo-kernel, jehož cílem je konečně instalovat kernel „the Gentoo way“, tedy bez potřeby ruční konfigurace pomocí make menuconfig, a zdá se, že většina mojí cílovky používá spíše OpenRC a genkernel než systemd a genkernel-next.

A v neposlední řadě mě už nebaví, jak někteří neustále vysvětlují, že nic jiného než systemd nejde používat, a přitom sami dokola papouškují, jak „dělají něco špatně“, když jim systemd funguje, bugy se neprojevují a žurnál se nerozbíjí. Já jsem na rozbitý žurnál za ten rok a půl taky přišel jenom asi dvakrát.

OpenRC rozhodně nepovažuju za nějaký zázrak. Jistě má spoustu chyb a návrhových nedostatků, ale to má systemd taky a jak výřečné má podporovatele. Ani se neplánuju systemd úplně zbavit, ale momentálně mi s originálním genkernelem tuším nebootuje a kombinace OpenRC a genkernel-next se trochu bojím, navíc se mi teď hodí kvůli výše zmíněnému projektu používat aktualizovaný =sys-kernel/genkernel-3.5.0.6.

       

Komentáře

[Bedňa]

Tak toto bude asi dosť komentovaný blog.

Mám stabilne na hlavnom kompe niekoľko distribúcií priamo na železe, pretože testovanie vo virtuále nepovažujem za rovnocenné a občas je to aj nevyhnutné ako je napríklad OpenCL.

antiX so sysVinit dáva stále rýchlejšie boot ako Ubuntu so systemd, no a fakt sa na tom Ubuntu pri reboote rozbíja žurnál, hoci doteraz som tam mal staršiu verziu antiXu a všetko chodilo OK, tak chybu disku by som neprisudzoval, keď sa prejavilo priamo s inštaláciou Ubuntu.

Ako bonus čo som postrehol, je súčasné spúšťanie procesov, takže Ubuntu s XFCE po prihlásení sa ešte minútu nedá používať až sa všetko načíta, nie nepodobné MS Win.

Nejak mi to už je dnes jedno, ale mal som pocit, že ťa v tom nemôžem nechať, keď sem v trhnú vyvolení.

Inak to XFCE a MATE mi kedysi prišlo fajn, po dlhšom používaní IceWM sa mi zdajú neskutočne obmedzené.

[pavlix]

Tak toto bude asi dosť komentovaný blog.

Sedm a půl hodiny pryč a zatím nic moc. ;) Navíc jestli přijdou argumenty již zmíněné v zápisku, tak nevím, jestli seberu sílu na ně znovu reagovat. :D

Nejak mi to už je dnes jedno, ale mal som pocit, že ťa v tom nemôžem nechať, keď sem v trhnú vyvolení.

Tak jako víš co, já jsem pro systemd fanboys teď rok a půl dělal to, že jsem to dobrovolně používal na svém laptopu a opravoval jsem jim služby, aby ten boot a další operace vůbec správně běhaly. Definitivně mě přesvědčilo, že mi někteří diskutéři jsou dosud schopni psát, že nadávám na něco/někoho úspěšného a sám vůbec nic nedělám, a přitom vesele používají různé výsledky mojí práce. Mně už prostě nebaví podporovat apriori „zmrdskou“ (Michal Kubeček odpustí, když je to v uvozovkách) komunitu, která se programově chová hrozně od core vývojářů až po nadšence v diskuzích.

Takže ano, rok a půl jsem kritizoval technickou i komunitní stránku, ale ve finále jsem dospěl k tomu, že nějaký kód umí psát kdekdo a vyšší prioritu si u mě nakonec získala lidská stránka celé věci. Takže ano, mám za sebou hromadu technických důvodů, ale je potřeba přiznat, že svoji váhu mají i ty netechnické, za což se ale člověk nemusí stydět.

Jinak systemd fanboys se můžou pod blogem vyjadřovat, jak chtějí, ale byly to ve finále oni, kdo mi poskytli jedny z posledních argumentů pro přechod k OpenRC, takže nevím, čeho víc by ještě mohli dosáhnout. Ale třeba se něco najde. :)

Inak to XFCE a MATE mi kedysi prišlo fajn, po dlhšom používaní IceWM sa mi zdajú neskutočne obmedzené.

Stále se držím i3 a zatím dělá přesně to, co potřebuju bez nutnosti nějaké extra konfigurace. :)

[Bedňa]

Ten komentár sa podobá dosť tomu, keď Linus písal, že by mal radšej v tíme nadšenca ako špičkového programátora s ktorým sa zle spolupracuje. Toto pravidlo asi funguje všade a keď ide o partičku IT nadšencov asi niekoľko násobne viac. Ono už to slovo spolupráca hovorí samo za seba.

Čo sa týka i3 proti tomu žádna. Keď som písal blogy neviem či zrovna tu, tak som sa práve o i3 zmienil ako o jednom z najlepších WM. Ešte je otázka či je tam taká priateľská partia ako u IceWM, kde sa cítim ako ryba vo vode :) To že som v jednom vydaní bol napísaný ako spoluator ma veľmi petešila a fakt mám rád svet spolupráce. Rovnako verím, že tu raz bude lešie miesto na zemi.

[kralyk z abclinuxu]

Tak toto bude asi dosť komentovaný blog.

Mně to připadá jako spíše nehořlavý materiál Prostě pavlix preferuje OpenRC, což je zcela v pořádku...

[Bedňa]

Pretože si občas píšeme a dosť toho napísal aj tu, tak mám pocit, že tá preferencia nieje len tak na truc, ale sú za tým skutočné dôvody. Takže horľavé to bude

[Michal Kubeček]

S IMHO velmi přesným vysvětlením přišel jeden kolega. Lennart podle všeho systemd bere jako jakýsi "research project" a v duchu toho funguje celý vývoj a (ne)správa. Implementují se různé vize, i když jsou někdy dost šílené, use case je podstatný jen když se podstatný zdá Lennartovi a spol., obecně se nebere ohled na to, kdo a jak systemd používá, bugy se řeší když je chuť atd. Kašle se na spolupráci s ostatními projekty, a to nejen těmi, které se nechtějí nebo nemohou přizpůsobit ("our way or the highway"), ale s těmi, které by spolupracovat chtěly ("udělat z toho knihovnu by bylo moc svazující, sada volně propojených object files je mnohem praktičtější").

Takových živelných projektů je samozřejmě spousta a většina z nich nevyvolává takové vášně jako systemd, dílem proto, že o většině se většina uživatelů ani nedozví. Čímž se dostáváme k tomu, co jsem psal už několikrát: hlavní díl viny za současný stav nevidím na straně Lennarta a jeho týmu; oni mají plné právo si takový hobby / research projekt vyvíjet a spravovat ho, jak uznají za vhodné. Pro mne jsou hlavními viníky manažeři většiny mainstreamových distribucí, kteří mávli rukou nad technickými a organizačními aspekty a z takto vedeného projektu udělali základní stavební kámen těch distribucí.

Nabízí se srovnání s Linusem, který sice jádro taky začal jako hobby projekt, ale jakmile viděl, kolik lidí (a později firem) ho používá, už dlouho se jim až úzkostlivě snaží neškodit. Koneckonců většina těch výlevů, kdy někoho seřve jako malého kluka, je právě kvůli tomu, že se některý high level maintainer snažil obhajovat porušení zásady "don't break the userspace". (Kernelové API a out of tree moduly, to je ovšem úplně jiný příběh.)

[vencour]

Nepletu se, že v Red Hatu 7 je systemd v základu a nejde se mu vyhnout? Ještě jsem sedmičku ani RHEL ani Centos nikde neinstaloval. A pokud je extended podpora pro RHEL 10 let, tak tam potom systemd zůstane celou dobu. Tohle mi na tom vadí, že se mu nedá vyhnout.

[Michal Kubeček]

Nepletete. Totéž platí pro SLE12.

[Heron]

K tomu bych přidal ještě další věc a to je chování lidí z RedHatu. Myslím běžné zaměstnance. To, že jsou všichni tajemní jak hrad v Karpatech, když jde o cokoliv co se týká RH, na to jsem si už tak nějak za ty roky zvykl. Jenže, když jde o systemd, tak to dostává další level.

Všechny bugy se buď zamlčují nebo zlehčují. Ve veřejné (no, ani v neveřejné) diskusi není možné technicky diskutovat chybu systemd, protože problém je vždy na straně uživatele (admina) a když už je to neokecatelné, tak je chyba v tom, že ten admin používá danou věc na špatném místě. Prostě chyba v sd se nepřipouští. Buď to používá blbě, nebo používá blbý prostředek. Maximum, co jsou někteří ochopni připustit je to, že je chyba v dokumentaci a že je špatně "komunikováno" k čemu daná věc slouží. Ale chyba v té věci rozhodně nikdy není.

Jako fakt nevím, jestli ti lidé mají povinnost šířit slávu sd, jinak nedostanou plat, nebo je RH nějaká sekta a ti lidi fakt věří tomu co říkají.

Jako vždyť je to jen software. Ti lidé se chovají, jako kdyby jim někdo sáhl na milenku.

[pavlix]

K tomu bych přidal ještě další věc a to je chování lidí z RedHatu. Myslím běžné zaměstnance. To, že jsou všichni tajemní jak hrad v Karpatech, když jde o cokoliv co se týká RH, na to jsem si už tak nějak za ty roky zvykl. Jenže, když jde o systemd, tak to dostává další level.

Protože ne všechny a ne všechno je dobré otevřeně kritizovat, pokud chceš, aby se ti dobře dařilo. Proto taky uvidíš daleko otevřenější přístup v češtině, kde se tak nějak příliš neočekává, že by to četl někdo, u koho by to mělo vadit. A kromě toho je brněnský office dost anit-systemd.

Jako fakt nevím, jestli ti lidé mají povinnost šířit slávu sd, jinak nedostanou plat, nebo je RH nějaká sekta a ti lidi fakt věří tomu co říkají.

No já nevím, ale mě při nástupu tvrdili, že je Red Hat firma, a to celkově dost otevřená, a zatím jsem nějak nestihl zjistit opak. Navíc mám pocit, že i tady na ábíčku se docela dost lidí projevovalo proti systemd a někteří i dost nevybíravě. Nevím, jaké vidíš třeba u mě šíření slávy. :D

Jako vždyť je to jen software. Ti lidé se chovají, jako kdyby jim někdo sáhl na milenku.

Ale kteří lidé? Většina ulítlých nadšenců třeba tady na ábíčku nemá s RH vůbec nic společného. A nakonec i Lennart považuje RH spíše za sponzora než za zaměstnavatele, podle toho, co se v tom projektu děje.

[Michal Kubeček]

Navíc mám pocit, že i tady na ábíčku se docela dost lidí projevovalo proti systemd a někteří i dost nevybíravě.

Souhlas. Já už rozhodně zaměstnance RH na systemd nadávat viděl.

A nakonec i Lennart považuje RH spíše za sponzora než za zaměstnavatele, podle toho, co se v tom projektu děje.

V tom je možná trochu rozdíl mezi SUSE a RH. SUSE je (relativně) malá firma, takže jsou vývojáři víc svázaní s tím, co ta firma dělá a odkud se berou peníze na jejich výplaty. (OK, to už se trochu mění, nemůžu třeba říct, že bych měl moc jasnou představu, čím se zabývají všichni ti lidé, které nabíráme na cloud. :-) )

RH je o dost větší a může si podle všeho dovolit zaměstnávat lidi, kteří si dělají svou práci zcela odtrženi od toho, jaké produkty firma nabízí a za co jí zákazníci platí. To jsou na jedné straně třeba maintaineři subsystémů jádra na plný úvazek, na druhé straně vývojáři provádějící na plný úvazek jakýsi "základní výzkum", aniž by se museli zabývat praktickými aplikacemi. Lennart Poettering se zdá patřit do té druhé skupiny.

[Heron]

Protože ne všechny a ne všechno je dobré otevřeně kritizovat, pokud chceš, aby se ti dobře dařilo.

Ano. Tolik k otevřenosti.

Nevím, jaké vidíš třeba u mě šíření slávy.

Pamatuji si, jak se tady před lety řešily některé věci v RH (ne ještě systemd) a ty ses tvářil, že v RH nepracuješ.

Ostatně to vyústilo až do tvé dnešní patičky: Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.

Ale kteří lidé?

Nebudu jmenovat. Nejedná se o lidi zde na abc.

[pavlix]

Ano. Tolik k otevřenosti.

Nevím jak otevřeněji bych to měl napsat. ;)

Pamatuji si, jak se tady před lety řešily některé věci v RH (ne ještě systemd) a ty ses tvářil, že v RH nepracuješ.

Jestli jsem se tvářil, že v RH nepracuju, pak to bylo před 2. květnem 2012. :)

Ostatně to vyústilo až do tvé dnešní patičky: Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.

To ne, to je patička, která vznikla na základě toho, že mě někteří méně důvtipní jedinci škatulkovali podle toho, kde jsem zrovna zaměstnán, a neustále mě obtěžovali kvůli věcem, které absolutně nebyly můj problém. A popravdě řečeno ta patička zafungovala skvěle.

[pavlix]

S IMHO velmi přesným vysvětlením přišel jeden kolega. Lennart podle všeho systemd bere jako jakýsi "research project" a v duchu toho funguje celý vývoj a (ne)správa. Implementují se různé vize, i když jsou někdy dost šílené, use case je podstatný jen když se podstatný zdá Lennartovi a spol., obecně se nebere ohled na to, kdo a jak systemd používá, bugy se řeší když je chuť atd. Kašle se na spolupráci s ostatními projekty, a to nejen těmi, které se nechtějí nebo nemohou přizpůsobit ("our way or the highway"), ale s těmi, které by spolupracovat chtěly ("udělat z toho knihovnu by bylo moc svazující, sada volně propojených object files je mnohem praktičtější").

Tak to do posledního puntíku odpovídá mojí zkušenosti.

Pro mne jsou hlavními viníky manažeři většiny mainstreamových distribucí, kteří mávli rukou nad technickými a organizačními aspekty a z takto vedeného projektu udělali základní stavební kámen těch distribucí.

V tom se naprosto vzácně shodujeme.

[Marián Kyral]

Genkernel jsem kdysi dávno v začátcích zkoušel, ale nakonec jsem si poctivě prošel všechny volby a získaný config teď už jen vždy nakopíruji k novému jádru, spustím "make oldconfig" abych se podíval na novinky, jestli by se mi něco nehodilo a pak už jen klasická kompilace.

Má pro mně smysl zkoumat genkernel? Co tam jsou za novinky?

[pavlix]

Má pro tebe smysl zkoumat kernel-tools, ale v tuhle chvíli je v tom docela bordel, protože teprve slučuju casterův a svůj projekt. Ten už zavolá genkernel tak, jak mi to vyhovuje a už brzo to celé schovám do emerge gentoo-kernel tak, jak to Vlasta popisoval v přednášce. A další na řadě asi bude výroba user configu pomocí menuconfigu. ;)

Ale vývoj vidím dost pozvolně, když zrovna bude nálada.

[Gilhad]

Doufam, ze old-school cesta stejne zustane nejakym zpusobem zachovana (treba prez USE, nebo jinak) :)

(prinejhorsim verim, ze si kernel proste fetchnu, rozbalim a nastavim rucne a nebude vyrazny problem se zbytkem systemu, ktery by ho vynucoval instalovat pouze new-way. Ostatne stejne pouzivam stary grub, protoze grub2 me nejak neoslovil a v Gentoo s tim zadny problem nemam. (ano, chapu, ze pro nekoho je grub2 prinosem tim, co vsechno navic umoznuje, ale pro me to zrovna jsou veci, ktere nevyuziju. Narozdil od systemd na tom nastesti zbytek systemu nijak nezavisi. Ostatne udev mi taky pije krev a kdykoli je problem se siti, tak zacnu promazavanim jeho adresaru a vetsinou to pomuze - je prima mit moznost "predikovatelneho jmena rozhrani enxa0369f2cec90" kdyz stridam sitovky jak ponozky a na pocitaci jich mam deset, ale pokud mam na kazdem pocitaci PRAVE JEDNU, davam prednost eth0 vswude, pred originalnim nazvem na kazde masine jinem - nastesti se to dosud da vypnout a da se dohladat, jak se to dela))

[pavlix]

Kdo ti brání?

[Gilhad]

Zatim nikdo a pral bych si aby pri tom zustalo :)

[Heron]

Já používám systemd několik let. Jednak proto, že se tomu v praxi nevyhnu (no i když...), taky proto, že rád zkouším nové věci.

Nebudu tady po tisící prvé opakovat, co všechno nefunguje, to je asi zbytečné.

Mě by spíš zajímalo proč to nefunguje. Já rozhodně systemd nepoužívám do hloubky. Na to jsou mnohem větší machři. Jenže i na tom povrchu nacházím věci, které buď rovnou nefungují, nebo jsou to pro mě wtf momenty. A že jich je.

Dva příklady:

FIFO sockety. Podle mě je to super věc. Systemd má socket activation, přičemž té službě potom předá socket. Může se jednat i o STDIN. Užitečné.

Socket je předán i když se ta služba nastartuje jinak než přes socket activation.

Jenže ta socket activation část se nedá vypnout. Rád bych měl tutéž možnost, předat fifo na stdin, ale bez toho socket activation. To tam prostě není. No nic. To je takový drobný WTF moment. Řeším to tak, že ten socket schovám na místo, kde ho nikdo nenajde. Tolik k systémovému řešení.

Dalším příkladem je věc, která nikdy nefungovala. Týká se to journalu. Journal prostě některým záznamům nedá atributy. Takže ve všech tutoriálech doporučované použití systemctl -u unit prostě nefunguje. Ví se o tom od roku 2012 a nikoho to netankuje.

Proč to píšu.

Ten první příklad je pro mě wtf moment, protože kdybych já něco takového psal, tak bych měl jako základ normální služby (start stop), potom by mě napadl geniální nápad předávat sockety a až potom by mě třeba napadlo, že by mohlo být dobré to pomocí těch socketů aktivovat. Všechno volitelně. Mám službu jako základ, můžu předat socket a můžu to i aktivovat. Proč je to v systemd naimplementované opačně mi není jasné. Ale ok, toto neberu jako chybu, ale jako chybějící vlastnost.

Ten druhý příklad je ale závažnější. Ta věc vlastně nefungovala nikdy. A opět, já nevím jak kdo, ale já když mám něco dělat, tak si nejprve zjistím, zda je možné to udělat. Jestli v tomto případě potřebují nějakou funkci v kernelu, tak je potřeba tam tu funkci mít předtím, než to začnou psát. Ne udělat nefunkční věc (strčit ji do každého návodu) a potom se na to 4 roky dívat.

[vencour]

No dobře. A tím chceš říct, že systemd v důsledku chválíš nebo tu pláčeš?

[Heron]

Jak co.

Třeba nspawn používám denně. (Jasně, roky je tu lxc, nspawn není ani první, ani nejlepší kontejner.) Na síť už nepoužívám nic jiného než networkd. Resolved taky slouží dobře (ok, teď je tam bug, ale ten se dá snadno obejít nastavením nsswitch.conf - používám testing/unstable na na sem tam nějaký bug jsem zvyklej). Takže toto chválím.

Potom jsou věci jako journal, které se pochválit prostě nedají.

Mě spíš zaráží ten způsob vývoje.

Prostě mi přijde, že nikdo nemá nějaký big picture (jak se hezky česky říká), naopak mají klapky na očích (alespoň ti, se kterými jsem se setkal) a kromě toho svého čtverečku nic dalšího nevidí.

[kralyk z abclinuxu]

Potom jsou věci jako journal, které se pochválit prostě nedají.

+1

[Petr Tomášek]

FIFO sockety. Podle mě je to super věc.

Jó, naprosto supr. „Díky“ tomu není možné remountnout rootovský filesystem (protože není možné zabít proces 0), ale kdo by chtěl takovou blbost taky dělat, že ano?

[Heron]

Proč by nešel?

mount -o remount,relatime /

Změnil jsem noatime (fstab) na relatime, no problémo.

BTRFS zapsal do logu to co píše u mountu běžně:

[Wed Nov 23 10:19:59 2016] BTRFS info (device sda2): disk space caching is enabled

A kupodivu i pid 0 běží v pohodě dál.

(A to o mě říkají, že jsem systemd.hater.)

[pavlix]

+1

[Michal Kubeček]

Nějak se nechytám… Co je to "FIFO socket"? "Proces 0" má být swapper? Jestli ano, jak s nimi souvisí? Nebo s remountováním kořenového filesystému?

[Heron]

Co je to "FIFO socket"?

https://www.freedesktop.org/software/systemd/man/systemd.socket.html

ListenFIFO=

FIFO socket je samozřejmě zkratka FIFO + socket activation. Jeden by si myslel, že to v daném kontextu bude jasné.

Proces 0" má být swapper?

Ne, jen systemd povýšil na jádro, takže místo původní 1 už je to 0. Tazatel se samozřejmě sekl, ale za to může (jak jinak ) Lennart, který na doméně 0pointer.net má povídání o PID Eins.

[Michal Kubeček]

Díky za částečné odmatení.

Jeden by si myslel, že to v daném kontextu bude jasné.

Dokumentaci k systemd čtu jen když není jiného zbytí. Zatím bylo. :-)

[pavlix]

Dokumentaci k systemd čtu jen když není jiného zbytí. Zatím bylo.

Dokumentace systemd není úplně špatná, jen nepokrývá spoustu zásadních praktických témat, ale jako reference funguje.

[Petr Tomášek]

Svého času, když jsem zkoušel distro se systemd mi to nedovolilo udělat mount -o remount,ro /. Od té doby mi systemd „do bytu“ nesmí.

[Michal Kubeček]

Na to by IIRC mělo stačit, aby na tom filesystému měl kdokoli otevřený soubor pro zápis. Příkaz "lsof /" by měl ukázat kdo a co.

[Petr Tomášek]

No, právěže mi ten lsof tenkrát za viníka označil systemd, o tom to celé je.

Kdyby to byl jakýkoliv jiný program než s PID 1, tak ho sestřelím a dál to neřeším, s initem to ale udělat nejde, v tom je zakopán pes...

[lnykryn]

Jenže ta socket activation část se nedá vypnout. Rád bych měl tutéž možnost, předat fifo na stdin, ale bez toho socket activation. To tam prostě není.

Docela by me zajimal presny use-case. Pokud chci mit dvojici sluzba-socket, ale zapinat to chci pres sluzbu, tak do sluzby muzu dat Wants a after na ten ten socket a socketu klidne i hodit RefuseManualStart, ale to asi neni pripad, ktery popisujete.

Takže ve všech tutoriálech doporučované použití systemctl -u unit prostě nefunguje. Ví se o tom od roku 2012 a nikoho to netankuje.

Predpokladam ze tam melo byt journalctl, ale s tim se nikdy problem nemel, muzete sem prosim hodit odkaz na nejaky issuer nebo bug, kde to bylo nahlaseno.

[Heron]

Docela by me zajimal presny use-case.

Existují programy (zcela konkrétně minecraft server), které se nechají ovládat příkazy posílané na stdin. Toto se dosud řeší tak, že daná věc běží v tmux / screen a přes send keys se tomu programu na stdin posílají příkazy. Program píše své informace na stdout. Jinak poslouchá na síti (přes kterou se blbě řídí).

Tohle řešení sice funguje, ale má vlastně jen samé nevýhody. Jednak se výstup toho programu (to co píše na stdout) nikam nezaznamenává (zrovna mc má vlastní log, ale obecně tam být nemusí), ale taky, když ten program v tom tmuxu sletí, tak se to potom z vnějšku blbě startuje.

Takže se to dá strčit do systemd jako simple service. Výstup toho programu (to co posílá na stdout) se automaticky loguje do journalu. A díky socket activation (resp mechanismu předávání socketů) se s tím dá kecat i přes fifo nasměrované na stdin. Takže tomu posíláte věci na stdin a odpovědi čtete v journalu.

Takže potud spokojenost.

Jenže je poněkud hloupé v situaci, kdy je ta služba vypnutá, když tomu pošlete na FIFO příkaz "stop". K vůli socket activation se ta služba nastartuje, přečte si příkaz ze stdin a potom se ukončí. To už je trochu blbé. Takže by bylo fajn mít možnost ten fifo na ten stdin napojit, ale vypnout socket activation.

Jako on to není až tak velký problém, dá se s tím žít, ale bylo by hezké mít možnost tu aktivaci vypnout.

Predpokladam ze tam melo byt journalctl, ale s tim se nikdy problem nemel, muzete sem prosim hodit odkaz na nejaky issuer nebo bug, kde to bylo nahlaseno.

Jo jasně, journalctl. Zde.

[lnykryn]

No a neslo by prave na tohle pouzit to moje zmninene reseni? Kdyz spustim server tak mi to predtim nahodi socket, ale jinak tam nebude. Mozna to bude chtit nejake bindsto, aby se ten socket zase vypnul kdyz se ukonci sluzba.

Ad https://bugs.freedesktop.org/show_bug.cgi?id=50184 Jo to budou ty short-lived procesy. Jeden kolega pro to psal patch do kernelu a bohuzel byl zamitnutej. Myslim ze tam bylo navrhnute i nejake reseni za pouziti kdbusu (i kdyz ted me nenapada jak), ale to taky nevyslo. Problem tam proste je ze mi dostaneme zpravu a nejsme schopni zjistit od koho prisla, protoze process mezi tim umre. V user-spacu tezko neco vymyslime, tam je potreba nejakou ficuru do kernelu, myslim ze na rhbz na to i mame bug.

[Heron]

No a neslo by prave na tohle pouzit to moje zmninene reseni? Kdyz spustim server tak mi to predtim nahodi socket, ale jinak tam nebude. Mozna to bude chtit nejake bindsto, aby se ten socket zase vypnul kdyz se ukonci sluzba.

Zkusím.

Problem tam proste je ze mi dostaneme zpravu a nejsme schopni zjistit od koho prisla, protoze process mezi tim umre.

Ale to je přesně to, o čem jsem psal. Ta věc správně nefungovala nikdy. A ví se o tom minimálně 4 roky. A není o tom ani čárka v sekci BUGS v man stránkách.

OK, pokud je ta vlastnost tak užitečná, že se někdo rozhodl to tam nechat, i když tam je zatím nevyřešitelná chyba, tak měl napsat do manu upozornění, že to nemusí vždy fungovat. Tohle je u různých programů v manu napsáno běžně.

Ne, místo toho je to -u ve všech tutoriálech a o chybě ani čárka...

Já na to přišel během 10minut. Při přepisu některých cronových úloh do one shot + timer. Potom jsem dva dny řešil, proč to tak je ... Jako workaround se dá použít -t a jméno toho příkazu (v ExecStart). Tam jsou záznamy otagované asi všechny (na problém jsem dosud nenarazil).

[kralyk z abclinuxu]

Ad https://bugs.freedesktop.org/show_bug.cgi?id=50184 Jo to budou ty short-lived procesy. Jeden kolega pro to psal patch do kernelu a bohuzel byl zamitnutej. Myslim ze tam bylo navrhnute i nejake reseni za pouziti kdbusu (i kdyz ted me nenapada jak), ale to taky nevyslo. Problem tam proste je ze mi dostaneme zpravu a nejsme schopni zjistit od koho prisla, protoze process mezi tim umre. V user-spacu tezko neco vymyslime, tam je potreba nejakou ficuru do kernelu, myslim ze na rhbz na to i mame bug.

Nevim, jestli se neptám úplně blbě, ale proč nemůže ty informace posbírat sd_journal_send() a předat je?

[heh]

Ja som po rokoch s linuxom a po umornej bitve so systemd presiel na windows na osobnom pc ... (presiel, by som na bsd - ale hw problemy). Mozem kaslat... nemam cas na taku blbost... Ked skonci podpora ubuntu tak na serveri co mam pod spravou dam bsd a budem dufat, ze tam sa nikdy systemd nedostane.

Ano je to subjektivny postoj a ano mam vsetko proti systemd. Ano mozem sa mylit a moze to fungovat, ale ja to nie som ochotny akceptovat. Ak chce ist linux a distribucie touto cestou ja ich necham a budem pouzivat nieco co mi vyhovuje.

[pavlix]

Ja som po rokoch s linuxom a po umornej bitve so systemd presiel na windows na osobnom pc ...

Když ti to vyhovuje. To by pro mě nebylo řešeňí a hlavně to vůbec není potřeba.

[R]

Na serveri je bezproblemovy Debian bez systemd. Na prechod z Ubuntu podstatne jednoduchsie riesenie ako BSD.

[Heron]

Já už dneska doporučuju BSD. Je to jednoduché, funguje to. Když mě nasere systemd tak to používám jako terapii

[jeste-centos-user]

bohuzel nemohu k hlavnimu tematu autoro nic moc rici, ale kdyz uz se tu nacla ta problematika systemd, tak bych mel nekolik poznamek.

Jak uz kolega Vencour nahore pripomenul, ta hlavni distribuce (RH/Centos) se rozhodla, ze bude pouzivat systemd a to na dost dlouhou dobu. My jsme zatim u Centos5 a prejdeme na Centos6, kde jeste porad muzeme pracovat jako v tech poslednich 20. letech. Problemy zacinaji byt ale s hardware. Na mensi zalozni servry se nabizi vyuzit ty nove lacine mainboardy s onboardCPU a tam uz to zacina byt problem s drivery u tech starsich distribuci.

Na druhe strane musim priznat, ze prace s yum repositari se mi zamlouva a rpm-soubory pro RH/Centos jsou podle mne nejlepsi zdroj pro aplikacni programovani.

V obdobi 1994-2004 jsem pouzivali Slackware - k nasi plne spokojenosti. Pak se ale zacalo objevovat stale vice software, kde bylo problematictejsi najit balicky pro Slackaware a proto jsem presli na Centos. Nyni si u na ve firme rikame, ze by nejlepsi bylo, kdybychom mohli pouzit jako zaklad Slackware a jako zdroj pro dalsi softwarove vybaveni RH/Centos repositare. Urcite nejsme prvni ktere to napadlo, tedy nedovedu si to predstavit.

Co si o tom myslite? Jake jsou nejvetsi problemy neco takoveho realizovat.

[pavlix]

Vím o jednom člověku, co takto Slackware používá. Mimochodem, pokud by měl někdo zájem oživit non-systemd variantu některé RPM distribuce, tak jsem ochotný do jisté míry pomoct, ale spíš konzultačně než maintanance, tedy spíše udělat změny, pokud se o ně pak někdo jiný plánuje starat. Považuju diverzitu (v tom pravém slova smyslu, ne SJW) za klíčovou vlastnost open source ekosystému.

[pk]

A co pouzit slackware + pkgsrc?

[pedro]

Co presne dela ten "gentoo-kernel"?

[pavlix]

Doporučuju přečíst relevantní dokumentaci. Odkaz na projekt je v blogpostu, tam najdeš README a tam najdeš odkaz na casterovy slajdy, které popisují jeho vizi v době, kdy se tomu aktivně věnoval. Moje vize je v něčem širší a v něčem trochu odlišná, ale to na projektu projeví postupem času. Nicméně pro základní pohled ty slajdy bohatě postačí a na zbytek stačí dát watch na projekt a počkat si na update README/TODO.

[pedro]

files?

[pavlix]

Moje chyba, sorry, README nemá gentoo-kernel, ale kernel-tools. Bude to asi potřeba trochu uhladit ještě.

[pavele]

Jaký filemanager používáš v IceWM?

Používáš ikony na ploše?

Síť nastavuješ ručně nebo přes wicd nebo NetworkManager?

Roky používám IceWm jako "záložní" WM, teď budu přecházet asi na Xfce z Gnome (nová instalace).

[pavlix]

Jaký filemanager používáš v IceWM?

Nepoužívám ani file manager ani IceWM, takže to asi bylo na Bedňu. :)