Ja popravde nechapu to saskovani proti systemd.
Systemd velice slusne a ucelene resi hromadu funktionality vcetne konfigurace cgroup slices, timeru services a hromady dalsiho.
Nic jineho rozsahem obdobneho neexistuje a placat to bash sktripty a crontabem muze jedine clovek,.co zamrzl v roce 98
Dnesni moderni linux roubovat SysV initem, to je jak montovat riditka z trojkolky na mercedes.
A kdo tvrdí, že _MUSÍM_ používat zrovna ten SysV??? Na svých strojích, bohužel kromě jednoho, mám OpenRC a oproti tomu jednomu kde bohužel je systemd se mi obecně pracuje lépe, protože vím co jak funguje a když ne, tak mám jednoduché oddělené logy které si prohlédnu i když nabootuji jiný systém.
No, já myslím, že tu svobodu v Devuanu pojali málo velkoryse, já bych byl pro to, aby Devuan umožňoval i běh s různými libc (glibc, musl, uclibc) a všechny varianty *SSL (OpenSSL, LibreSSL, BoringSSL, wolfSSL, atd...). Tohle je málo svobodné!!!
Nebo že by to vlastně vůbec nebylo o svobodě?
Není, protože PŘECI SI NENECHÁM OTRÁVIT SYSTÉM libsystemd knihovnou!!! :-P
Jak píšu, celý Devuan není postavený na technických důvodech.
Ne každý je odvázaný z Rube Goldbergova stroje kterej se stane neovladatelnej, když přestane třeba fungovat dbus.
Tak se podivejte na OpenWRT a jeho odvozeniny... vc. treba TurrisOS :-) A podivejte se treba i na ruzna "profi" reseni typu QNAP ci treba ruzna zarizeni od Ubiquity. A muzeme pokracovat dalsimi priklady - a klidne treba u firem typu Cisco. Nekde a nekomu to smysl proste z nejakeho duvodu dava... no a? Je to prece kazdeho volba... a taky odpovednost.
"Systemd velice slusne a ucelene resi hromadu funktionality vcetne konfigurace cgroup slices, timeru services a hromady dalsiho."
A třeba s tímhle mám já docela problém. Ne takový, abych měnil distro, ale vadí mi to. Systemd míchá dohromady věci, které mají být nezávislé. Proč má být dohromady init systém, task scheduler, logovací daemon a spousta dalších chujovin? Nechť je tam API, ale ať jsou to nezávislé (a nahraditelné) projekty.
Ale to se prece da do velke miry povypinat a nahradit 🧐
Napriklad systemd-journald se da vypnout a muzes ti tam dat treba rsyslog.
Misto systemd-resolved si muzes dat treba dnsmasq.
No, ne. rsyslog můžete pověsit za journald, ale oddělat jej nemůžete. resolved můžete nepoužívat, ale pořád tam je.
Kde je resolved? Já ho vůbec nemám nainstalovaný. V Debianu je to samostatný balíček.
Co se týče Journalu - všichni brblají jak je na prd (včetně mě), ale pořád nikdo nenapsal alternativu (API mezi systemd a journald jistě existuje), která by logovala per-unit do textových souborů a rotovala to jako za starých časů. Takže to asi nikomu zas až tak moc nevadí.
Jestli to nebude spis tvoji lenosti ... pouzivam treba metalog, a co kam se bude logovat si snadno nastavis, pokud to nejak logovat umi a umi se to nejak itentifikovat, tak to muzes libovolne rozdelit. Muzes snadno docilit i toho, ze budes mit jeden log kde bude "vsechno" a zaroven dalsi kde to bude rozdelene, coz se hodi kdyz hledas nejaky casovy souvisloste.
Jup a jsou to textovy soubory na ktery ti vi/cat/... staci.
Pekny, lec ja nyni, ve stoleti ančovičky, vidim vsade prosty journald, coz, pro debug tracing naprosto postacuje a umim si z nej udelat "oddelene logy" prepinacem --unit.
A kde je potreba delat s logama krapet vazneji, cpe se to do vzdaleneho OpenSearch, kde se daj ty data prosivat v ramci cele farmy kooperujicich serveru.
"Pekny, lec ja " ... o logovani nic nevim. To si chtel rict? Logy jsou totiz zajimavy predevsim v situaci, kdy neco crashne, a logovac systemd crashuje jako prvni.
A kupodivu a neprekvapive, kdyz crashne logger, tak se ani do vzdalenyho logovace nic nezapise ... ja vim, divny.
Ju vlastne, ja zapomel, systemd "resi" problemy tak, ze vsechno porad dokola restartuje.
Provokace:
Ve Windows je to všechno jeden projekt a nikdo si nestěžuje. Kromě pár aktivistů je to totiž uživatelům jedno, dokud to funguje. A ti aktivisti si budou stěžovat vždy, i když to funguje.
SysV init byl hromada osmdesátkového zmatečného bordelu. Nevím proč, ale musel jsem tvořit nějaké záhadné konfiguráky na kdovíco, aby alespoň něco fungovalo. Od příchodu systemd to dělat nemusím. Jako uživatel a zároveň správce vlastního serveru jsem spokojen.
No nikdo si nestěžuje do takové míry, že na serverech, pokud to není nutné, Widle nikdo nepoužívá.
Nic méně já jsem nepsal, že systemd je špatný init systém (a nevím, proč se pořád srovnává s SysV příšrností), já jsem psal, že do něj byly naházené věci, co tam prostě nepatří a kdyby Poettering mohl, tak jsme tu asi měli systemd-desktopd, systemd-coffeed, systemd-toiletd a nakonec i systemd-coffind.
Vzdyt je to spousta drobnych utilit presne v duchu unixove filozofie. V cem je systemd coby cisty init system spatny? Resi to zavislosti sluzeb na sobe, jejich izolaci / hardening, limity zdroju, monitoring vc. restartu pri padu sluzby... v zasade vse, co od moderniho initu realne potrebujete. Nic vam nenuti pouzivat vsechno ze zminovaneho souboru, mnohe z tech drobnych utlit jsou jen doplnky, bez kterych jde existovat.
A je hezke si brat do huby Poetteringa, ale ono to spis vychazi z pozadavku, ktere prichazi od enterprise zakazniku. Systemd neni rozhodne zadna one-man show, kde si kopnete do jednoho cloveka. Ta poptavka po poradnem init systemu tu byla, byly ruzne jine pokusy nahradit SysV a ty mely podstatne vic much. Bastly typu pocatek init scriptu je vlastne komentarova konfigurace pro zavislosti, kterou si neco "nejak" prezvejka nemluve. Casto zadratovane natvrdo v kodu... kdy samozrejme to udrzitelne zmenit byl pak problem - ten "patch" vam rozbil kazdy update baliku. Se systemd napisu jeden override file, se kterym se pocita a ve kterem muzu v pohode ty parametry distribucni unity upravovat...
Co je tak těžké pochopit na větě: "Nic méně já jsem nepsal, že systemd je špatný init systém, já jsem psal, že do něj byly naházené věci, co tam prostě nepatří."?
Já jsem nikdy neměl problém se systemd jako init systémem, ale má zůstat init systémem a ne celým userlandem (a to prostě tlačil Poettering). Chápete to, nebo to potřebujete nakreslit?
No vzhledem k tomu, ze jste si vyfabuloval neexistujici komponenty vlastne neni zrejme, co ze povazujete za chybnou soucast. A opet utocite na cloveka, ale ono tady se nebavime o nejake one-man show.
Takže to bude potřeba asi nakreslit. Jinak součástí systemd jsou: journald, libudev, localed, logind, hostnamed, homed, networkd, resolved, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd. A to s různou mírou zadrátovanosti (minimálně závislost na kterékoli komponentě znamená závislost na systemd a z něho závislosti na některých součástech, třeba journald je typický příklad), to jako považujete za čistý init systém, jo?
To jsou ale samostatne pouzitelne nastroje. Samostatne binarky, chcete-li si to namalovat. A ze ty binarky zavisi na nejake knihovne? No to uz tak milej pane chodi... kazda binarka ma svoje zavislosti. Samotny init na nich nezavisi, pouze jej funkcne obohacuji - ale jde fungovat i bez nich.
A zrovna journald je typicky prikad toho, jak pricetne delat logovani v 21. stoleti. Jiste, porad muzete mit marast oddelenych textaku, kde si pak nejaky chytrak usmysli, ze prida svuj vlastni - oddeleny, ale jaksi opomene jej rotovat... a vyrobi vam tikajici bombicku :-) Typicky hate pochazi od lidi, kteri journald vlastne neumi pouzivat...
1. Nejsou to samostatně použitelné nástroje.
2. Jasně, například tranzientní závislost NTP na logovacím daemonu, je naprosto normální
3. journald je příčetné logování? Tak to toho asi moc nespravujete. To je vhodné tak možná na desktop.
4. 11. 2025, 10:19 editováno autorem komentáře
Ano, chod NTP chcete logovat. Minimalne situace, kdy nefunguje jak ma. Co je na tom divneho? :-) Vy snad (ne)fungovani NTP nelogujete?
A samozrejme, ze logovani pres journalctl se pouziva lepe, nez ruzna "grep" alchymie nad po disku roztahanymi textaky. Uz jen takove malickosti journalctl jako --since, --until, --unit...
To je asi jako vysvětlovat opici teorii relativity. Vy prostě evidentně nic nespravujete a prostě nevíte. Víte, jak se v linuxu loguje? No, evidentně nevíte. `--since`, `--until` atd. to je fakt raketová věda. Co je proti tomu například různá retence logů dle aplikace? Výsledek journald je, že se stejně nepoužívá a přeposílá se to do souborů, nebo rovnou na nějaký stack , ale s journald nikdo přímo nepracuje a je to jen trpěná komponenta, která nejde oddělat.
Ono jsou tam i dalsi veci, jako treba integrita logu. Aneb jak u toho "tradicniho" syslogu zabezpecite, ze se v tom nahodou nekdo nepohrabal? ;-) Ono je tak tezky ten textak zmenit, a tim treba i skryt nejakou nezadouci aktivitu, ze? (jiste, to jde vyresit tim, ze log poslu i jinam - ale bavime se o lokalnim storage) Napriklad instantne komprimovany zapis logu je take praktictejsi, nez textakovy tradicni syslog - kde kdyz se neco necekane zblazni, tak ten diskovy prostor mizi pomerne rychle, ze? :-) Ale zda se, ze to jste pane "zkuseny" nikdy nezazil...
Ale vase tvrzeni, ze nikdo s tim nepracuje je proste blabol. Nepracuji s tim predevsim hateri systemd, kteri se proste odmitaji ucit neco noveho, protoze jsou prece dvacet let zvykli neco delat...
Pan zkušený ví, že na logy je oddělený volume a když se něco zblázní, tak tomu ani komprese nepomůže, jen to oddálí. A taky ví, že lokálně uložené logy se tailují a zpracovávají jinde (zejména pro security). A co se učení nových věcí týče, tak s tím problém absolutně nemám, ale když je něco k ničemu, tak tomu nic nepomůže. Krásný rozdíl je mezi servicema v systemd (dobré) a logováním v systemd (na prd).
Ne nebavime. Jakmile chcete integritu, autenticitu a podobne vlastnosti logu, typicky logujete ihned pryc. Casto neverite ani lokalnimu zdroji dns, ntp apod. Pouze chcete, aby jadro co nejrychleji a hlavne bez zbytecnych prostredniku, informace poslalo pryc. Lokalni zaznamy at uz s souborech, nebo v db pak slouzi maximalne jako honeypot.
Naopak pro bezne stroje napr. pro uzivatele, je podle mne log soubor diky sve jednoduchosti a beznym vlastnostem (napr. offline cteni) rozumnejsi volba.
Journald ale nejakou integritu resi. Nebo snad chcete zpochybnit Forward Secure Sealing? Copak v nem vidite za problem?
> Napriklad instantne komprimovany zapis logu je take praktictejsi
Já jsem tady a na AbcL dělal benchmarky velikosti journalu vs. ekvivalentního syslogu (textového) za stejný čas, a journal z toho vždy vyšel mnohonásobně hůře - neuvěřitelně větší. A následně to další uživatelé reprodukovali - v jedné diskuzi dokonce i vy osobně. (příklad takové analýzy) Nerozumím tedy, proč to tu znovu píšete - nebo se s novou verzí systemd/journald něco změnilo a už to komprimuje? Výše uvedený test je na Debianu Trixie (v době psaní komentáře asi měsíc před vydáním), čili dosti nové verze.
Kdyz ono je to tezke - vam prijde jako "problem" ukladani metadat, ktere mj. umoznuji jednoznacnou identifikaci puvodce dane zpravy. A jinak pomoci konfiguracni volby Compress muzete i upravovat parametry/chovani te komprese, pokud se vam nelibi default, obcas to chce juknout do manualu... pripadne u starsich instalaci zrevidovat, jestli se tam z minulosti neprenesl nejaky artefakt, co stav spise zhorsuje.
> Kdyz ono je to tezke - vam prijde jako "problem" ukladani metadat
Ta metadata jsou ale podezřele velká, nebo jich je zbytečně mnoho, nebo jsou nevhodně uložena.
> A jinak pomoci konfiguracni volby Compress muzete i upravovat parametry/chovani te komprese, pokud se vam nelibi default, obcas to chce juknout do manualu...
Tak se pochlubte, jakých výsledků dosahujete vy. Třeba je to opravdu jen mojí/naší neschopností / výrazně neoptimálním defaultním nastavením.
> jestli se tam z minulosti neprenesl nejaky artefakt, co stav spise zhorsuje
Šlo o čerstvou instalaci Debianu Trixie (tehdy verze po prvním zmražení).
Ta metadata jsou ale podezřele velká, nebo jich je zbytečně mnoho, nebo jsou nevhodně uložena.
Můžu se jen zeptat, proč to vlastně řešíš?
Ptám se proto, že disky na serverech jsou tak velké, že řešit kolik má log (typicky 30 dnů) jsem za 20 let nemusel vlastně nikdy. A kdykoliv někdo chtěl nebo potřeboval ukládat logy navždy, tak přinesl tak velké pole, že mi z toho spadla brada.
A ta poznámka o metadatech mi připomněla situaci, kdy se někdo divil, proč ten "můj" postgresql má tak velká data a že se to dá určitě uložit úsporněji. No .... ano, pokud si napíšu vlastní storage, do kterého budu ukládat pouze golang struct v gob, tak to bude skutečně několika násobně menší, ale otázkou je, jestli chci pro každý projekt psát vlastní storage (nechci) a nebo jestli prostě použiju (ano!) univerzální datový typ BYTEA, případně to rozhodím do sloupců. A u mne vyhrává stále to druhé. A pokud vím, že těch logů bude opravdu hodně, tak to naházím do PG prostě ve standardních gobech do bytea a napíšu další program, který to potom postupně rozhodí do dalších tabulek.
Až budu psát simulátor galaxie, tak záznamy o těch 100mld hvězd určitě do PostgreSQL ukládat nebudu, ale na obyčejná data to zatím bohatě stačí.
"Ptám se proto, že disky na serverech jsou tak velké, že řešit kolik má log "
Spousta serveru zadny disk nema, a loguje treba na nejaky SDcko, ktery je jednak maly, druhak se zbytecne osoupava.
Spousta serveru zadny disk nema, a loguje treba na nejaky SDcko, ktery je jednak maly, druhak se zbytecne osoupava.
Tohle někdo viděl v praxi? Jednak disky jsou doslova spotřební zboží, takže výměna vadných disků je od určitého počtu práce na plný úvazek a od doby přechodu na DC Intel SSD (od roku 2014 a tehdy P3500) je jejich životnost zatím mnohem lepší, než u rotačních disků.
> Můžu se jen zeptat, proč to vlastně řešíš?
Velikost mě zas tak netrápí, ale když někdo tvrdí, že je journal komprimovaný a menší, tak to uvádím na pravou míru.
Co mi vadí nejvíc je UX:
- rychlost výpisu (journalctl | grep trvá také řádově déle než textový soubor, a to i když je textový soubor zagzipovaný - jo, možná má journal nějaké interní rychlejší vyhledávání, snad)
- otevřu si journal, otevře se v lessu, zmáčknu end, a to nejde, protože to generuje výpis viz výše a to trvá. Takže musím rovnou při otevírání journalu dávat -n 2000, --since nebo něco a doufat že to bude stačit.
- když mám ten otevřený journal v lessu a zmáčknu end, tak se nedonačtou nové věci (protože to journal už vypsal a skončil a už si povídám jenom s pagerem). Oproti tomu když v lessu mám otevřený soubor a dám end, tak ho to přenačte a vidím nové položky. Obdobně lze v lessu zmáčknout "F" a přepne se jakoby do režimu "tail -f". Takže jediná možnost jak vidět nové věci je journalctl -f, ale v tom logicky zase nejde scrollovat
- nejde nastavit různá doba uložení různým věcem jinak než že použiju úplně oddělené journaly
- nejde smazat specificky jednu unitu co se zbláznila a zaplevelila logy a zbytek nechat
- a už vůbec nejde u zblázněné unity smazat zprávy odpovídající regexu a zbytek nechat
Ok, já používám automaticky -f s kombinací určitého počtu -u, takže na pager nenarážím.
Pokud se nějaká služba zblázní, tak to vidím v monitoringu a ne až v logu.
Pri mesicni retenci... takovy bezny server (nginx/php/maria/postfix...), na ktery i chodej lidi.
$ du -sh /var/log/journal/ 1.3G /var/log/journal/
neprijde mi to jako cislo, ktere by mi melo nejak zvlast trhat zily :-) Zijeme v 21. stoleti, fakt neprovozuju masiny s 200MB harddisky.
Metadata osobne za dulezita povazuju - vzhledem k fungovani tradicniho syslogu, kdy "pachatel" nemus byt nutne na prvni pohled zrejmy a kdy vzhledem k "primitivnosti" samotneho protokolu se obcas sovy nemusi jevit tim, cim jsou, zeano...
Škoda, že jste jako všichni hujeři opominul fakt, že jednodušší nástroje, které třeba naprosto stačí často není zdaleka tolik třeba umět používat. Když vám dám do ruky bagr, taky ho dost pravděpodobně (minimálně statisticky pravděpodobně) nebudete umět používat narozdíl od lopaty, kterou bravůrně zvládnete (přinejhorším po krátké instruktáži) za pět minut.
A celé to opravdu neznamená, že je horší bagr nebo lopata. Jsou to dva nástroje pro jiné případy užití. Bez kontextu tvrdit, že jedno je lepší než druhé je nesmysl.
A tak jiste, nekdo radsi bude tyden kopat zaklady lopatou... jen aby se nemusel ucit s bagrem a mohl nadavat na pokrok :-)
A zase ty tvoje demagogie. Mimochodem, ty používáš bagr pokaždé, když potřebuješ přehrabat dětem pískoviště?
Za prvé, není to tak dávno, co jsem se účastnil kopání základů lopatou a krumpáčem, protože bagr v daném místě by byl nesmysl. Zhodnotili jsme, že lopatou to prostě bude rychleji.
Za druhé, nikdo tu neříká, že všude bude používat lopatu a nikde bagr. Píše, že občas se hodí lopata, občas se hodí bagr.
Za třetí, pokud něco lopatou vykopu rychleji, než se naučím s bagrem, má cenu učit se s bagrem?
Za čtvrté, pořizovací náklady - slušný bagr je trošku dražší a náročnější na provoz nez lopata.
Za páté, journald je skutečně trpěná a útrpná komponenta. To, co mám během pár minut hotové nad textovým souborem s logy, to s journald hledám násobně déle. A to už si konečně pamatuji alespoň základní parametry.
A vy pouzivate na detske piskoviste lopatu? :-)
Ano, dava se smysl ucit nove veci - i kdyz tim prvotne treba stravim vic casu. Nabyta zkusenost se typicky hodi vickrat - a nemusim nutne vedet dopredu, kdy ji budu (opet) potrebovat.
Bagr si porizovat nemusite, ono v dnesni dobe neni zas takova magie si jej nekde proste pujcit.
Ze vam veci s journald trvaji dele je spis obraz vasi nesikovnosti :D
> Jinak součástí systemd jsou: journald, libudev, localed, logind, hostnamed, homed, networkd, resolved, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd.
Větší polovinu z uvedeného nepoužívám ani nemám nainstalovánu, u některých věcí dokonce ani nevím, k čemu slouží. Pro věci jako networkd, resolved, timedated jsou naprosto zjevné náhrady ze kterých si můžete vybrat (jakýkoli network manager preferujete, jakýkoli DNS server preferujete, jakýkoli NTP klient preferujete).
Budu tu trochu proti sobě (sám časy před systemd pamatuju a zlatá situace teď), ale výhrady chápu. Respektive chápu, co vidím jakej je problém s X11 a přechodem na Wayland. Jak systemd prorůstá celým ekosystémem okolo Linuxu a jak se na něm stávají závislé i další projekty, bude jednou strašnej problém ho nahradit i kdyby se objevila lepší alternativa. Stejně jako je teď problém nahradit X11 Waylandem + kompozitorama => hromada appek a využití stojí na všemožných funkcionalitách, co poskytuje X11 a je problém to nějak jednotně nahradit, aniž by byl stvořený nově nabobtnalý projekt, nebo naopak totální Babylon napříč kompozitory.
Já teda nejsem žádný velký systemd nadšenec, ale zrovna ty vyjmenované věci dělá celkem dobře a nejsou to zrovna nové nápady. Task scheduler (ať je to cokoliv) postavený na událostech je super nástroj. Hromada služeb může mít socket activation, takže se spustí až po příchodu packetu na jejich port. Potom služby, které jsou závislé na nějakém disku (třeba síťovém) se nemusejí spouštět, když ten disk není dostupný. (Ano, zrovna tady jsem se systemd zažil srandu, když mount unita nadšeně namountovala disk z pole, který jsem opravdu nechtěl namountovat jako RW, resp v této fázi vůbec.) Logovací démon sice nemusí být nutně součástí init služby, ale stav před tím vypadal tak, že se syslog měnil za rsyslog a rovnou se to posílalo někam do ElasticSearch, aby se to dalo používat. Místo toho stačí zavolat journalctl -f -u nginx -u php-fpm a vidím, jak na to obě služby zareagují a vidím to na dvou řádcích po sobě. A právě na tohle (sledování souvisejících služeb) se vždy používaly externí nástroje.
A jestli tím schedulerem byl myšlen třeba timer, tak to je opět velmi výhodné, protože na rozdíl od cronu, kde se 500 úloh zapnulo ve stejný čas (i když to nebylo nutné), tady stačí dát AccuracySec=1h a systemd to spustí podle aktuální zátěže a situace. Navíc ví, co bude spouštět, takže ví, jestli to vlastně může spustit (jestli to takhle reálně dělá nevím, napadlo mě to až při psaní tohoto textu).
Takže jsem po těch letech se systemd spokojen. Když měli všechno od počátku postavené na cgroups, tak se přímo nabízelo udělat kontejnery a od roku 2016 vlastně nic jiného než nspawn na linuxu nepoužívám. Dneska jdou služby kontejnerizovat do jisté míry i přímo v jejich service konfigu a nastavit omezení paměti, cpu apod. A vzhledem k tomu, že je to vlastně strom všech dalších procesů, tak se to nastavuje mnohem lépe, než dřívější ulimit.
Dále to ve své době mělo konečně rozumné nastavení sítě, kdy v jednom konfigu (resp ve více souborech, ale stále je to ini formát) nastavím bridge, vlan, přejmenuju iface apod. Ve starých network scripts to byl doslova porod a stačilo, aby někdo tam dával postaru iface aliasy a někdo ne a potom nástroje (dodnes velmi oblíbeného) jako ifconfig (nešlo by to konečně definitivně zahodit?) tak jeden admin tam viděl 60 IP adres (ip) a druhý třeba jen "svých" 5. V době, kdy si tam každý balíček může přihodit vlastní network konfig podle toho, jaký typ iface zrovna potřebuje tohle odpadá.
A věci jako NTP a DNS resolver se také přímo nabízejí, protože obé je podmínka nutná, nikoliv postačující pro provoz produkčního serveru. Takže nainstaluju minimal debian, je tam automaticky systemd a automaticky všechno, co kromě mého procesu potřebuju. Takže nemusím nastavovat další služby čistě jen pro základní provoz v roli serveru.
Tedy ne, že by to nešlo jinak, ale serverů, kde chyběl NTP jsem taky viděl hodně. Dneska stačí timedatectl set-ntp true a je to.
A ta modularita tam do jisté míry je. Nevím vlastně proč, ale zrovna debian oddělil nspawn a resolved do vlastních balíčků.
Sockety jsou asi v pohodě. Ale třeba vezměme ten cron (například). Ano, ten má opravdu dost nedokonalostí, ale to není důvod, proč jej míchat s init systémem. Už jenom ty konfigurace máte pak naházené mezi servicema, proč? To není o tom, že by ty komponenty systemd (povětšinou teda, ten journald mi pije krev od začátku a asi toho nenechá) fungovaly špatně, to je o tom, že jsou provázané víc, než by bylo zdrávo. Tam se pak otevírají bezpečnostní problémy, kompatibilita, (ne)přizpůsobitelnost atd. Ta filozofie jedna "aplikace"="jedna činnost" má svůj smysl. Systemd to úplně bortí.
Timer je sluzba jako kazda jina. Zrovnatak pri startu mate sluzby, ktere se jen spusti, vykonaji co je potreba a pak svuj beh ukonci. A i tady doslo k ucesani - zatimco cron mate rozesety na mnoha mistech (nekdo to pise naprimo do /etc/crontab, nekdo do /etc/cron.* adresaru, nekdo do /var/spool/cron/crontabs ), timery jsou prehledne na jednom miste. V tomhle smeru systemd nic neborti, spousteni a kontrola behu sluzeb dle definovanych kriterii (ktere muze byt i casove/periodicke) je prace init systemu.
Já s vámi souhlasím. Po přechodu na FreeBSD (na serverech) jsem teprve viděl, co vše jde udělat správně i v prostředí sahající až někam k MULTICSu a vše napsaném v původním sh. Po instalaci FreeBSD core mám v zásadě úplně všechno, všechno nastavené a všechny potřebné služby jsou jednak přímo core, ale také nainstalované, nakonfigurované a spuštěné. Takže nastavím ssh klíč, dám tam vlastní službu a je to. A nebo ani to, fw, nfs, iscsi je přímo v core, takže postavit diskové pole na FreeBSD je jen instalace core, nastavení zfs datasetů a hurá na export přes NFS.
Linuxové prostředí se do tohoto stavu dostává vlastně dodnes. Měli jsme RHEL, ale tam v core vlastně nic není a co appka, to další repositář. Po přechodu na Debian (2012) bylo rázem všechno v základních repositářích, ale zase se nedokázal rozhodnout, jestli je pro desktop nebo pro server (nebo potom pro tablet). A třeba NetworkManager na serveru opravdu nechci (se vším jako wpa-supplicant apod.)
Ta filozofie jedna "aplikace"="jedna činnost" má svůj smysl. Systemd to úplně bortí.
Ač se mi to nechce psát, tak systemd ale je systém jedna appka jedna činnost. Na všechno kromě pid1 je tam další služba. A pomocí API komunikuje se zbytkem. A to, že místo další implementace timesyncd někdo (rhel) přišel s chronyd je mi vlastně dodnes záhadou.
A já vlastně od počátku své kariéry v IT programuju podobně, jak je stavěn systemd. Za jádro považuju data, takže všechno je v PostgreSQL a kolem toho další služby, které se o ta data starají (import, export, analýza, zpracování dat apod.)
A skutečně nevím, co je tak špatného na tom mít konfiguraci .timer unit v /etc/systemd/system. Kde jinde by to mělo být? V crontabech jednotlivých uživatelů? Což jde mimochodem taky, v systemd může mít každý uživatel vlastní systemd --user unity a své vlastní timery.
Co má znamenat v daném kontextu to "core"?
FreeBSD tým řeší kromě samotného kernelu taky vlastní programy (něco jako coreutils). Takže při instalaci lze zvolit kernel, base (core), porty. kernel+base je vlastně nejmenší možná instalace a i bez dalších balíčků (pkg nebo porty) je tam toho vlastně dost, takže na tom lze postavit samostatný server (bez dalších balíčků).
Tak samozřejmě - jádro je jen část (ta menší) operačního systému. A FreeBSD je, na rozdíl od Linuxu, operační systém. Proto to "core" nedává v tomto kontextu smysl - prostě jste si nainstaloval FreeBSD a nakonfiguroval jste si v něm server. ;)
Jenže tady je podstatné to, že o kernel a base systém se stará stejný tým a je to na tom opravdu vidět. Podpora pro jaily je ve všech systémových příkazech, stačí dát parametr -j a už konfigurujete kontejner. A asi nejhezčí případ je soft-updates pro UFS2 v době, kdy ext2 se rozhodovala, jestli bude mít journal, tak UFS2 mělo snapshoty (i když omezený počet) a journal se obešel právě jiným způsobem update kritických struktur ve fs. A tenhle jeden FS jim vydržel vlastně až do nástupu ZFS.
V systemd to funguje podobně, stačí dát některým příkazům parametr -M a už nastavujete nspawn. Ale už vidím, jak někdo "nutí" implementaci -M i do dalších programů v repositáři. ;-) (To jen takové rýpnutí.)
Takže ona "konfigurace" serveru ve FreeBSD se vlastně rovná jen jeho instalace. A pokud je to pro můj program, tak jedna binárka, konfig a služba a je hotovo.
Tohle jsem na linuxu nikdy nezažil. Jasně, u systemd stačí binárka, unita, konfig, ale potom někdo přijde s tím, že chce docker, takže dockerfile, potom někdo LXC a tak dále.
Jako já jsem psal, že cron rozhodně není dokonalý. Ne vlastně je spíš na kopanec. Ale třeba není to tak dávno, co jsem potřeboval dynamicky generované crontaby dostat do k8s a cronjoby na to nebyly vhodné (kvůli té appce, to nebudu rozebírat) a teď mi poraďte s timerem...
Jako fakt bych radši novou reimplementaci cronu, spíš nějaký svébytný anacron, ale timer to není.
a teď mi poraďte s timerem...
Já nevím, co konkrétně řešíte, ale generovat konfigurační soubory pro timer jde snadno.
Ale musíte tam mít puštěný celý systemd a to, že byste si konfiguraci přimountoval z volume, tak to asi moc nepůjde.
Ale musíte tam mít puštěný celý systemd a to, že byste si konfiguraci přimountoval z volume, tak to asi moc nepůjde.
Já nevím, co myslíte tím celý. Systemd v nspawn je typicky jen a pouze pid1, který spouští služby. Nic dalšího tam neběží, protože je to jaksi kontejner. Takže v případě mých nspawn kontejnerů jeho vnitřní systemd spustí jenom ssh a třeba nginx. A tím jeho role končí.
A pokud v kontejneru potřebujete kromě jednoho procesu té služby, pro který je ten kontejner vytvářen i něco jako cron, tak se bez nějakého dalšího managera stejně neobejdete. Tuším, že docker má nějakou možnost správy interních procesů, ale víc o tom nevím. Já provozuju pouze nspawn a jaily (na freebsd).
Nevím, tohle jsem nezkoušel, ale s cronem prostě v kontejneru s aplikací přidám a pustím crond (a kdyby to nebyl cron, tak nějaký soft, který by to uměl), není potřeba nic víc.
Však to je u desktopu záležitost vyloženě pár okrajových dister. U specializovaných dister (Alpine např.) to pak smysl dává vzhledem k use-casu (byť i systemd se dá osekat na poměrně minimalistickou implementaci).
Výhoda Linux světa je především ve svobodě výběru. Většina uživatelů benefituje ze systemd a kdo nechce, nemusí. Pokud mu to tak vyhovuje, super pro něj. Byť ji upřímně taky nechápu, ale nikterak mě nepohoršuje.
Windows také velice slušně řeši hromadu balastu a konfigurace. A stejně jsem rád, že jsem z nich už hodně moc let pryč. To opravdu není argument. To, že vám něco vyhovuje je vám přáno. Ale to neznamená, že to, že někomu to nevyhovuje je špatně. A psát, že něco nechápete je jako psát na fórech, že vůbec nechápete, jak někdo může používat Windows. Nebo nedojedená jablka. Nebo cokoliv jiného. Nesmysl.
systemd bylo tlačeno silou a diverzita je téměř zničena, tak nám těch posledních pár mohykánu nechte.
Tím, že budete dokolečka omílat nepravdu o tom, že někdo něco někam tlačil, se z toho pravda nestane. Budete se muset smířit s tím, žesystemd v Debianu vyhrál po dlouhé debatě, a protože byl technicky nejlepší. O ostatní varianty se nikdo v podstatě nechtěl starat. Jestli si myslíte, že si Debian nechá jednoduše něco natlačit, tak se prostě pletete.
Budete se muset smířit s tím, žesystemd v Debianu vyhrál po dlouhé debatě, a protože byl technicky nejlepší. O ostatní varianty se nikdo v podstatě nechtěl starat.
Kde sa potom vzal ten Devuan?
já se ale nebavil o přechodu Debianu, ten se odehrál v době kdy už v podstatě bylo rozhodnuto a příliš alternativ nebylo a stávalo se čím dál složitější je udržovat.
RedHat prostě vytýčil směr, kterým se bude linuxový svět ubírat a ostatní už dřív nebo později tu změnu museli přijmout.
Nicméně na vzniku dister jako Devuan je vidět, že i přes ten tlak a kladené překážky kdy jádro je čím dál více se systemd provázané, je tu stále poptávka po něčem jiném.
ja nechapem preco by som mal pouzivat nieco od redhatu povinne.
Ja som jeden z tych antisystemovych, Devuan, MX linux a antix su jedine distribucie ktore mam a pouzivam
SystemD sa stal akýmsi symbolom aktivistov, ktorý si zo SW dokážu spraviť božstvo a každého, kto by si azda dovolil použiť niečo iné pokladajú za hriešnika, na ktorého treba ukazovať.
Rovnako dnes funguje wayland alebo v minulosti PulseAudio. Je to skrátka smer, ktorý Korporácia zadefinovala ako progress a každý, kto nie je s nami je spiatočník, fašista a zamrzol v roku, keď to ešte fungovalo :)
Jenže zrovna PulseAudio je příklad, jak věci nedělat. Stačil přechod na Pulse a původní nastavení 96kHz/24b přestalo fungovat (protože pulse prostě nestíhal) a ještě navíc tam bylo nastaveno 44.1/48kHz, takže aktuální samplerate se měnil podle toho, který zvuk se přehrál jako první, takže konzistence nula a do toho někdy nutnost resample a jindy ne, takže ještě navíc změny latence + nutnost resample ostatních streamů. Takže jsem si pulse nastavil tak, aby na jednu zvukovku nesahal a mixoval jsem si to v mix pultu na stole. (Ale jak jsem se před lety dozvěděl, tak Pulse je super, protože někomu zrovna v něm fungují BT sluchátka, takže každý máme jinou představu o HiFi. :-D)
Jen pulseaudio je uz davno za svym zenitem a diskutovat o nem je totez jako snazit se osedlat mrtveho kone :-)
A už ho nahradilo něco, co funguje bez toho, aby se samplerate snížilo na 1Hz? :-D
Linux na desktopu nemám, ptám se vážně. Mám stále v todo projekt, že do Marantze dám něco jako RPi se zvukovkou AudioQuest DragonFly (super!) a udělám z toho analogu digitál :-D Ale tak nějak automaticky chci nastavit max, tedy 96/24, aby vážka svítila stále stejnou barvou. Svého času jsem k tomu zesáku měl připojenou destičku Asus board (něco jako RPi 1), která měla z tehdy dostupných desek nejkvalitnější audio čip, hrálo to super a měl jsem tam alsu a mpd.
A to ma nejake prakticke uziti a nebo jde jen o vystrelek z kategorie "protoze muzu"? :-) Nevim, na linuxovem desktopu muziku i filmy bezne poustim, ale tohle jsem nikdy nemel potrebu resit... rad se ale obohatim, k cemu mi to muze byt dobre. Druhemu odstavci jsem asi neporozumel :D
A to ma nejake prakticke uziti a nebo jde jen o vystrelek z kategorie "protoze muzu"
Já teda nevím, na co přesně reaguješ, ale já mám poměrně jednoduchý default. Nastavit maximum, co umí HW. Takže pokud každá integrovaná zvukovka (čip stojí méně než dolar) na desce umí automaticky 192kHz/24b, tak nastavím 192/24 a tak nějak počítám s tím, že to prostě bude fungovat. A s příchodem PulseAudio se vrátily nadávky na netopýry apod. Já si prostě zjednodušuju život nastavením maxima a pokud někdo chce zkoumat, co kde zrovna slyší a vidí a nastavuje si monitor třeba na 6b místo 10b, tak je to jeho boj, ale zase u toho nemusí nadávat lidem, kteří nastaví všude max.
A když už mám doma Marantz a Bowers and Wilkins, tak prostě chci, aby nic, byť třeba jen teoreticky, neomezovalo data po cestě. A jestli těch 80kHz slyším nebo neslyším, tak do toho nikomu nic není.
A tohle je dlouhodobá zkušenost. Ze všech foťáků ukládám raw a někdy jsem moc rád, že tam ta data ze všech těch pixelů jsou (znám lidi, kteří mají i na zrcadlovce rovnou nastaveno ukládat pouze jpeg). Proč bych se měl zbavovat byť třeba zrovna nepotřebné informace jsem vlastně nikdy nepochopil. Pokud ta data nikdy nebudu potřebovat, tak je to vlastně jedno, ale naopak, když je budu potřebovat, tak tam prostě jsou.
A tak pri zbeznem pohledu do dokumentace pipewire nastavit 192kHz/24b v pohode zvladne. Ale feedback vam neposkytnu, zas takovy audiofil nejsem :-)
No ono to papírově zvládalo i Pulse, ale potom tam nastoupil resampler, který řekl ne (co se týče nároků na CPU). Takže i na prvním Ryzenu nešlo dělat v Pulse to, co uměla levou zadní Soundblaster Audigy (která měla HW audio mixer, takže resampler nebyl potřeba). Takže jsem to vyřešil po svém, na stole mám mix pult, do kterého hraje několik zvukovek podle toho, co zrovna dělám (jedna na hry do sluchátek, druhá na HiFi a integrovaná na desce pro zbytek). Dneska signálové procesory sice umí hromadu vstupů, ale tak na deskách máme obyčejný DA "kodek" (nevím, proč se tomu tak říká, je to prostě simple DA převodník), který chce data v přesné podobě.
Žádný závěr nedělám. Ty ses jenom podíval do dokumentace a tam jsi něco našel, ale nenapsal jsi, že jsi to vyzkoušel. Stačí vytáhnout audacity a osciloskop a otestovat to. Jestli někdy v geologicky dohledné době budu mít linux na desktopu, tak to samozřejmě otestuju. Snad se mezitím ze Slunce nestane červený obr, ale tak to bych ještě stihnout mohl.
Ze Systemd se jedno vyvine nový Windows a půlce linxářům z toho hrábne.
Systemd popírá linuxovou filozofii, že by jedna utilita měla dělat jednu věc, zato pořádně.
systemd je kolekce utilit. Je to jako stěžovat si, že coreutils kopíruje soubory, počítá SHA-256, převádí do base64 a faktorizuje na prvočísla. Nebo možná dokonce jako stěžovat si, že GNU projekt obsahuje kompilátor, kernel, textový editor a nevím co dalšího.
coreutils ale má kopírovat soubory, má počítat sha-256, má převádět do base64 a má dělat spoustu dalšího, protože to je userland. Ale init system nemá logovat aplikace, nemá synchronizovat čas, nemá cachovat DNS, nemá čistit tmp, atd. Stejně jako aplikace na počítání hashů nemá stahovat e-maily.
Ale tohle je dobrý post. A právě o tom to je. Systemd měl být náhrada SysV initu. RH nejdřív experimentoval s upstartem (RHEL6) a pak přešel na systemd. A právě tohle je problém, systemd měl být init system, byl náhrada původního initu, ale Poettering měl vizi, že do toho předělá půlku systému (přinejmenším). A to je přesně důvod, proč je systemd tak kontroverzní. Zajímavé je, že vždycky někdo vyrukuje s hláškou o SysV initu, ale právě, jak jste psal, systemd není init system, ale ten je jen jeho součástí.
Systemd is a software suite for system and service management. Mozna namisto projektovani vlastnich predstav byste si mel precist, co to doopravdy je. Ono do spravy systemu a sluzeb spada cela skala veci, zeano :-)
"Ta poptavka po poradnem init systemu tu byla, byly ruzne jine pokusy nahradit SysV a ty mely podstatne vic much."
Váš vlastní post.
Za to ctvrtstoleti s Linuxem jsem tech pokusu par zazil. A po technicke strance je systemd zatim nejlepsi, zadne bastly pres komentare v init scriptu.
Init system ale neloguje, a uz vubec necachuje DNS, necisti tmp.... to mate dost popletene. Nejspis proto, ze nevite, co ktera komponenta doopravdy dela :-) Vetsinu z toho, co zminujete jsou proste jen dalsi implementace nejake cinnosti a nikdo vam ji fakticky ani nevnucuje.
A ono jentak mimochodem nejde journald zamaskovat? :-) Kdyz uz me tedy takova blbost napadne udelat...
Můj systemd teda uvedené věci nedělá. Jsou to samostatné balíčky, samostatné programy, některé vůbec nemám nainstalované (cachování DNS - hostnamed, čas - timesyncd), ty co možná nainstalované mám (čištěné tmp - nevím která komponenta to dělá) nejsou aktivované. A ani jsem se o to nějak nesnažil, je to defaultní konfigurace v Debianu - instaluje a spouští se právě jen ten init systém.
(technicky, timesyncd jsem si doinstaloval, protože jiné NTP věci mi nevyhovovaly, například se rozjely když jsem uspal notebook, nebo měly tendenci poslouchat veřejně do internetu. Ale nic mě k tomu nenutilo a klidně si používejte openntp nebo co zrovna frčí)
Jediné co beru je logování (journald), to je podle mě opravdu řešené špatně. Dá se nastavit, že se vůbec nebude používat a okamžitě se přepošle do syslogu, ale souhlasím, že to je zbytečná komplexita navíc.
Jen aby nás to taky časem nepotkalo. Podle mě je to podobný efekt, jako když si imigranti do hostitelské země importují i to, co bylo fakticky prapříčinou jejich emigrace. Většina linuxářů je odkojena Windowsy a unixovou filosofii vlastně nikdy za svou nepřijali. Takže si GNU/Linux postupně přetvářejí v Lindows. Což nemusí být zas taková katastrofa - pořád podstatně lepší varianta než MS Windows. Ale byl bych rád, kdyby aspoň BSD zůstalo unixem.
Nás s FreBSD mučili na škole, prezývali sme to FreeBDSM. Ja som rád, že tí imigranti vyžadujú, aby sa k ním systém správal lepšie.
Mě zas klienti mučí Windowsy. Stav, kdy se k nějakému nastavení musím pokaždé proklikávat - a v každé verzi jinudy, o horroru jménem registry ani nemluvě, místo abych jednoduše, jako člověk, zadal příkaz, zeditoval příslušný soubor, nebo si na obojí napsal skript, kterým si to celé zautomatizuji, když se to hodí, rozhodně nelze nazvat lepším chováním OS. Honění myši po stole a vyplňování formulářů zase já považuji za podivný fetiš generace odkojené Windowsy.