Kernelfejlesztőket kérdeztek, hogy mit jelent a "d" a systemd-ben ...

HUP cikkturkáló

Egy vicces értelmezés szerint arra utal, hogy a systemd 500 komponensből áll ...

  • 2357 megtekintés

( NevemTeve | 2025. 10. 21., k – 09:40 )

Szvsz az ötszáz azért elég sovány a valósághoz képest... Ha még tudnánk gondolkozni, és tudatosítanánk, hogy egy önértékelés terén súlyos kihívásokkal küzdő ember (aka hybris) konkrétan mindenbe belenyúl, ami a rendszerünkben fut, sikítva menekülnénk.

Szerencsére senki sem közvetlenül használja a termékét, hanem a disztróján keresztül. Tehát előtted már sokan átnézték a kódot, és jónak találták ahhoz, hogy bekerüljön.

Az nem véletlen, hogy gyakorlatilag mindenki systemd-re állt át. Persze, lehet mindenki hülye, de valami alapjának legalább kell lennie, különben nem használnák.

 

Amúgy meg ugyanez pepitában a macos launch -ja, meg a dózerben is van valami hasonló, most nem jut eszembe a neve.

 

Egész egyszerűen kellett valami, ami figyel változásokra, és triggerel dolgokat, amikor megtörténnek. Persze lehet 129 különálló szervert indítani egyesével erre, de egyszerűbb összefogni egy rendszerbe, és elnevezni "event handler and reconciler"-nek, vagy akár röviden systemd-nek. :D 

( hrgy84 | 2025. 10. 21., k – 15:45 )

>  Tehát előtted már sokan átnézték a kódot, és jónak találták ahhoz, hogy bekerüljön.

Ó te kedves, nyári gyermek.

>  Persze, lehet mindenki hülye, de valami alapjának legalább kell lennie, különben nem használnák.

Hype. Legfőképp.

> Egész egyszerűen kellett valami, ami figyel változásokra, és triggrel dolgokat, amikor megtörténnek. Persze lehet 129 különálló szervert indítani egyesével erre, de egyszerűbb összefogni egy rendszerbe, és elnevezni "event handler and reconciler"-nek, vagy akár röviden systemd-nek. :D 

Cserébe single point of failure-é válik ez a rendszer. Azaz ha itt valami hiba van, akkor nem tudod megkerülni, nem tudsz megoldást adni, csak imádkozhatsz. Normális supportja nincs, mert hát openszósz. Amúgy az eseménykezelésre ő is az uDevD-t használja, tehát ez pont nem a SystemD feladata.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Egy initrendszer esetén a support hogy néz ki szerinted? Mert pl. Windows alatt mondjuk a Notepad-nek van normális supportja? Ezt szerintem nem egészen gondoltad át.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A syslognál sem definiált, hogy a logfájl az bináris vagy nem, a szabvány sem írja elő a plain textet.
A syslog-ng is tudja binárisan is tárolni a logokat, ha úgy állítod be.

Ha te logokat akarsz olvasni, akkor nem egyértelmű, hogy azt tudod-e plaintext kezelő eszközökkel olvasni, mert a rendszerben bármikor lehet bináris a logfájl, nem definiált, hogy az, vagy nem az.

> A syslognál sem definiált, hogy a logfájl az bináris vagy nem, a szabvány sem írja elő a plain textet.

Akkor olvasd át a szabványt. Már a fejlécnél is 7 bites ASCII kódolásról beszélnek, legfejlebb az üzenet lehet bináris.

> A syslog-ng is tudja binárisan is tárolni a logokat, ha úgy állítod be.

A journald viszont alapból nem tudja plantextben tárolni a fájlokat. Azért van textual representation egyáltalán a legtöbb disztróban, mert az rsyslog felnyalja a journald által kifosott bitkolbászt.

> Ha te logokat akarsz olvasni, akkor nem egyértelmű, hogy azt tudod-e plaintext kezelő eszközökkel olvasni, mert a rendszerben bármikor lehet bináris a logfájl, nem definiált, hogy az, vagy nem az.

Ez biztos valami modern mentalitás, mert az alkalamzások döntő többségének amúgy van plantext logja, amit szabad szemmel is lehet olvasni. Csak néhány kereskedelmi alkalmazásnál láttam eddig, hogy kizárólag bináris blobokat állított elő. Jobbára inkább a kivételek szintén fordult ez a SystemD/JournalD páros előtt ez elő, a hibahatár alatt.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Akkor olvasd át a szabványt. Már a fejlécnél is 7 bites ASCII kódolásról beszélnek, legfejlebb az üzenet lehet bináris.

Van szabvány a log formátumra? Lemaradtam valamiről? Az RFC5424-ben valóban van ilyen, de az az on wire protokoll, köze nincs a logfileokhoz et al.

> JFYI: Normális rendszereknél a logokat nem az adott hoston dolgozzák fel.

Annyira szeretem, amikor ilyen féligazságokkal dobálóztok. Persze, kizárólag mindenhol csak enterprise rendszerek léteznek, óriási architektúrába szervezve. Olyan pláne még csak véletelenül sincsen soha, hogy meggebed a hálózat, és lokálisan, az adott hoston kellene logokat olvasni debugolás céljából. Ami hálózatot mellesleg alapból sokszor szintén a SystemD egyik bugos alrendszere orchestrál.

Ne akarjuk már validálni azt, ami józan ésszel ránézve az architektúrára agyfasz. Van egy csomó jó és hasznos feature-e a SystemD-nek, ezt elismerem bármikor, de attól még se nem jó konstrukció, se nem jó szoftvertermék. És míg annak idején a SysV initet meglepően gyorsan ki lehetett cserélni akár egy Bash scripthalmazra is, addig manapság mindenbe beleeszi magát a SystemD/DBus függőség, ha ki akarod szedni a rendszerből, lényegében nem lehet. Ezzel szenved az OpenRC is egy ideje, ki tudják váltani a SystemD-t, de... és jönnek azok a részfunkciók, amiket mindenképp be kell emelni, hogy egyáltalán eljusson a rendszer a login promptig. Ehhez képest az upstart maga volt a pőre igénytelenség szobra, carrarai márványból.

Én nyitott vagyok a változásokra is, nem véletlenül tanultam bele a Kubernetesbe is. De attól nem lesz valami kevésbé szar. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Annyira szeretem, amikor ilyen féligazságokkal dobálóztok. Persze, kizárólag mindenhol csak enterprise rendszerek léteznek, óriási architektúrába szervezve. 

Nem, mondom normális rendszereknél. A rendszer nem 1db számítógép ha már van 3 géped akkor sem helyben dolgozod fel. Lehetnek kivételek, de ez a 99.99%-ra igaz.

 

Olyan pláne még csak véletelenül sincsen soha, hogy meggebed a hálózat, és lokálisan, az adott hoston kellene logokat olvasni debugolás céljából.

És szerinted a log forwarder mit csinál? Nincs hely ideiglenes tárolás? De az nem a feldolgozásra vonatkozik, hanem a működésre. Ha olyan helyzetet akarsz alapesetként kezelni "meggebed a hálózat" ami egy hibás működés, akkor el vagy tévedve. Nekem ne gyere azzal légyszi, hogy a logok akkor kellenek ha baj van. 
 

Én nyitott vagyok a változásokra nem véletlenül tanultam bele a Kubernetesbe is.

Akkor talán alkalmazhatnád is, mert pl. az egy jó példa, miért nem kell helyben feldolgozni a logokat. 

Már megtörtént dolgokról beszélünk. Gyakorlatilag nincs olyan disztró, ami teljesen SystemD független lenne, még ha ezt is állítja magáról. Sure, az init rendszer OpenRC, de egy csomó kis modulka kell a SystemD-ból, mert az opensource világ ráült a hype vonatra.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A systemd projekt részei közül semmit sem kötelező használni, sem a resolved, homed, journald stb. Semennyire sem kell használnod. Ha a disztribúció úgy dönt, hogy használja, akkor pedig tőlük kapsz támogatást rá.

Amúgy különítsük el azt, hogy systemd-t mint szoftvert értjük (ami az init rendszer és service manager)vagy a systemd-t mint  projektet értjük, az alá tartozó egyéb szoftverekkel (systemd-homed, systemd-resolved és társai).

Ez valóban nem segít, de azért nem ez az egyetlen oka. Egyrészt van ez az ideológia basz, hogy túl sok minden van túl összefonódva benne, másrészt meg vannak ennek egyértelmű előnyei a gyakorlatban (meg a hátrányai is nyilván). Nyilván nem segít Pöettering főni csudálatos stílusa se, meg hát azért volt benne bugi is rendesen (természetesen a minden másban is), meg hát a featureök minősége is változó, van néhány kifejezetten jó része, néhány elég fos, a többség kissé hintázik a meh, good-enough vonalon (tegnap pl nem először szembesültem azzal, hogy hát jó ez a journalctl, de azért így helyenként lehetne flexibilisebb). Összességében nem egy igazán "szerethető" szoftver.

Imho a nemszeretem bagázs azért szeret kevésbé fontos dolgokat túlfújni, meg azért néha nem látják a fától az erdőt. Amikor minden egyben van, akkor pfujj, mert a unix way az a do one thing but do it well, miért van benne ennyi minden a systemd-ben, a másik oldalon meg mikor pl a DEk úgy vannak vele, hogy ők inkább írnának DE-t akkor, és basszon nyugodtan a session managementtel pl a logind, nem tartanak karban ugyanarra mind egy-egy saját megoldást, számukra marginális területen, akkor meg az a baj, hogy jajjdependency....

Ezzel együtt, azért tény, hogy rendesen széttarabolni részeit egyáltalán nem triviális, valószínűleg alternatívákat biztosítani és karbantartani se az, nyilván nem véletlen nem sokan csinálják.

De hát pont azért áll sok komponensből a systemd projekt, hogy UNIX elvek mentén composable legyen a rendszered. És felépítheted a rendszeredet a SysV komponensek helyett systemd komponensekből. Egyáltalán nem látom a problémát, nem egy monolitikus szar. Az más kérdés, hogy egy olyan sok komponensből álló rendszer, amit egységes elvek mentén, együttműködésre terveztek. De hát ilyen minden kereskedelmi UNIX is manapság. 

Nekem nincs problémám azzal, ha valaki SysV stílusú rendszert szeretne, de azért lássuk be, az elmúlt 35 évben rájöttünk arra, hogy annak milyen hátrányai, kényelmetlenségei, korlátai vannak. Pont ezeket akarja a systemd projekt megugrani, és adni egy egységesen kezelhető alaprendszert, ami a GNU komponensek mellett oprendszert csinál.

Talán ahhoz tudnám hasonlítani, hogy míg a *BSD projektekben az egyes OS-szintű eszközöket a projekt maga fejleszti, addig a GNU/Linuxnál ez sosem volt így, és a systemd projekt pont ezt akarja megcsinálni. És akkor lehet rá tényleg dependálni, szépen UNIX módra összelegózni a funkcionalitásokat - csak éppen a legózás egyes elemeit ugaynaz a "gyár" állítja elő, és nem ezerféle implementációra kell felkészülnie a dependens szoftvereknek.

Azt akarja kezelni, ahol a POSIX szabványosítása már véget ér, és meg vannak lőve a fejlesztők, hogy na akkor most mit is feltételezhetünk a runtime-ról, mit és milyen formában biztosít a szoftveremnek.

Teljesen egyetértünk, én is így látom a helyzetet, épp a két megmondás közötti ellentmondásra akartam felhívni a figyelmet, hogy hát kissé van-e rajta sapka helyzet van.

És jepp, azt nem írtam, de egyébként valóban pontosan az a legjobb benne, hogy ez egységes elvek mentén, összedolgozásra van (és ezt nem szokták érteni azok, akik a túl bonyolult, és össze van nőve, nem elég elkülönült darabokból van állásponton vannak). Hogy a darabjai lehet hogy meh, a timerek lehet hogy kevésbé tetszenek mint egy cron, meg bonyibbnak tűnnek, cserébe össze vannak nőve rendesen a service managementtel, nem kell körbevarázsolni. Hogy lehet, hogy resolved pfujjpfujj, mert beletolakodik a resolve.confba, és "nem tudod mi történik" (egyébként de), meg vannak miatt szopások (hello docker és resolve.conf másolgatás), cserébe amikor a network manager felhúz egy openvpnt, akkor a split tunnel beállítások alapján beállítódik magától a megfelelő resolve routing. Meg ilyenek.

Elolvasva a linkelt KB cikket, nekem pont úgy néz ki, hogy a journald továbbra is ott van, továbbra is fut, és minden log ami a _systemd-ben keletkezik_ a journald-be megy. Csak éppen a bináris logfájlját nem írja, hanem azonnal forwardolja az rsyslogd-nek.

Az egy teljesen másik kérdés, hogy az alkalmazásaidat/service-eidet a saját konfigfájljaikkal külön konfigurálhatod, hogy máshova logoljanak (ha támogat ilyet). Illetve - ha van erőforrásod karbantartani a service file overlay-eket minden vicik-vacak service-re - akkor persze egyedileg eltérítheted a default stdout/stderr logolását journald-től máshova. De ettől még a journald nem szűnik meg a systemd kötelező függőségének lenni, ellenben sok más systemd-szatelit vackokkal, amik tényleg opcionálisak.

Régóta vágyok én, az androidok mezonkincsére már!

Idéznék belőle:

Edit the journald configuration at /etc/systemd/journald.conf; switch journal to in-memory only mode and enable forwarding:
[Journal]
Storage=none
ForwardToSyslog=yes

 

Create drop-in for the rsyslog unit configuration file at /etc/systemd/system/rsyslog.service.d/logging.conf with the following content to ensure socket creation and linking:

# https://access.redhat.com/articles/4058681
[Unit]
Requires=syslog.socket

[Install]
Alias=syslog.service

 

Load the drop-in file, and restart services:
Raw

# systemctl daemon-reload
# systemctl enable rsyslog.service
# systemctl restart rsyslog.service
# systemctl restart systemd-journald.service

 

Man:

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=

    Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, sent as wall messages to all logged-in users or sent over a socket.

A man nem írja le értelmesen, hogy ez konkrétan a syslog.socketet jelenti, de mi mást jelentene (különös tekintettel, hogy bool value a forwardtosyslog)

Szóval de, a journald service fut, és keresztülfolyik rajta minden, ő teszi ki a syslog socketre.

 

Szerk: Ha azt szeretted volna mondani, hogy egyéb dolgokat irányíthatok direktben a syslogra, az természetesen igaz. Csak hát ez azt nem támasztja alá, hogy a systemd menne a journal nélkül (tippre ha kikapcsolod menni fog, de a felőle jövő logok rohadtul nem fognak kijönni sehogyse)

# systemctl restart systemd-journald.service

Kikeresed magadnak hogy mi a különbség a disable és a restart között, vagy megtegyem neked? A SystemD nem működik journald nélkül, és ezt a KB cikk is elég nyilvánvalóvá teszi, miután sehol nem tiltja le a journald-t. Az továbbra is fut a memóriában, és átmegy rajta lényegében minden fontosabb üzenet, csak in-memory marad. Azért van ez így, mert a SystemD nem képes működni journald nélkül.

De győzz meg az ellenkezőjéről, bizonyítsd be, hogy ha letiltod teljesen a journald-t, akkor utána a SystemD boldogan átvált rsyslogra. Mert ezt jelentené az úgynevezett modularitás.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Kikeresed magadnak hogy mi a különbség a disable és a restart között, vagy megtegyem neked?

Nem kell, tudom. Pontosan ezért emeltem ki, hogy persicsb kollégának is feltűnjön, hogy az ő linkjén is egy restart van, szóval futni fog a journald.

Nem lenne baj, ha alacsonyabb lovat keresnél, ha már ennyire nem sikerült megérteni, amit írtam. Egészen konkrétan le is írtam, hogy ettől még nincs letiltva, és a systemd dolgainak kell.

Azaz ha itt valami hiba van, akkor nem tudod megkerülni, nem tudsz megoldást adni, csak imádkozhatsz. 

Mi van? Melyik init rendszernél nem így van? Mikor adtál meg más init binary-t kernel bootsorban legutoljára?  

Normális supportja nincs

Azt ugye tudod, hogy az RHEL és az Ubuntu is systemd-vel van szállítva? Én értem, hogy semminek értékeled az enterprise támogatást, de attól még nagyon nincs rendben amit írsz. 

i.e.: lehet a systemd-t szeretni/nem szeretni, lehet azon is dühöngeni, hogy nincs igazi versenytársa, de azért a tényeket nem kellene elferdíteni. 

( Raynes v | 2025. 10. 21., k – 17:15 )

Meglepett a válasz, azt hittem én is, hogy d=deamon. Nem mintha számítana.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Lehet én értek félre valamit, de szerintem a videó komoly, és tényleg az a-c verziók utáni verzió. Fura, de hihető. Bár abban igazad van, hogy legyünk fenntartással, lehet valami kamu AI-s videó is, ami csak hitelesnek látszik.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Ice | 2025. 10. 22., sze – 17:31 )

Szerkesztve: 2025. 10. 22., sze – 17:42

D, mint "Disaster". Tegnap 2x próbáltunk DR-t egy szerveren (REAR-rel szépen ment vissza SLES15 SP6-ra, ott se indult el az SAP, csak néha) SLES15 SP7 upgrade után nem indult el az SAP(csak néha, mint a mesében),  vagy az SAP vagy a SystemD hibás, vagy mind azok. :)

 Tegnap 2x próbáltunk DR-t egy szerveren (REAR-rel szépen ment vissza SLES15 SP6-ra, ott se indult el az SAP, csak néha) SLES15 SP7 upgrade után nem indult el az SAP(csak néha, mint a mesében),

Erre vonatkozik a megállapításom, hogy üzemeltetésből elégtelen. Az, hogy te ezt személyes sérelemként dolgozod fel, az a saját szociális problémád.

Nem, a leírásból annyi látszik, hogy mind a systemtré, mind a SAP egy fos, és nehéz különválasztani, hogy melyik okozza a gondot. Nyilván valahol skill issue is, de aki ilyen szutykokkal dolgozik, az rá is van szorulva a csoda skill-ekre, az tuti.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Bár nem tudom jelen esetben mi a konkrét probléma forrása - lehet, hogy a konkrét service file-ban van elrontva valami -, de az általános tapasztalatom nekem is hasonló.

Ha tényleges reliability kell, mondjuk HA corosync, ill pacemaker clusterrel... Vagy akárcsak egy periodikus healtcheck és watchdog automatikus újraindításhoz... Na akkor kezdenek a systemd service management bugjai előmászni a sötétből.

Addig tkp egész jól lefedi az alap használati eseteket (jobban, mint ahogy anno SysV vagy BSD init scriptekben bármilyen tákolással meg lehetett oldani), de a HA-környéki használati eseteknél kiütköznek a 15+ éves, azóta sem javított bugok. Megbízhatatlan systemd-notify, és emiatt fals módon triggerelődő watchdog és társai... A Wants=, DependsOn= stb. függőségkezelés anomáliái. Hogy nem tudod rendesen megoldani, hogy melyik visszatérési érték számítson "retry-olós hibának", melyiknél adjuk fel azonnal és hagyjuk failoverelni amilyen gyorsan csak lehet.  Ilyenkor tényleg az szokott a vége lenni, hogy ki kell venni az adott service-t (service tree-t) a systemd kezelése alól.

Régóta vágyok én, az androidok mezonkincsére már!