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 ...

  • 1858 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 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)

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.”

( 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. :)

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!