( bzt | 2024. 04. 07., v – 18:57 )

Arpi_esp-nek teljesen igaza van, mi a halálnak kell kommunikálni oda-vissza? Bőven elég annyi, amit a signal nyújt, ráadásul ezeket a parancsokat a systemd küldi a service-nak, és nem pedig fordítva a service a systemd-nek! A visszafele iránynak semmi értelme. (Az meg már csak hab a tortán, hogyha nem standard módon ellenőrzi a service állapotát, hanem elhiszi, amit az magáról állít, akkor könnyedén inkonzisztencia alakulhat ki. Pl. mi van akkor, ha egy service elküldi a "rendben elindultam" jelzést, majd bedobja a törülközőt. A systemd ilyenkor képtelen újraindítani a service-t, mert a legutóbbi üzenet miatt azt hiszi, minden okés. Konkrétan szoptam már ezzel.)

Hullára felesleges a libsystemd, csak arra jó, hogy mivel szarul van megírva, támadási felületet adjon, másra nem. Egy szolgáltatásnak tök felesleges bármilyen infót is küldeni az init-nek, bőven megfelel a célnak egy pid fájl is. Abból már lehet tudni, hogy elindult-e sikeresen, és ha igen, akkor kinek kell a signalokat küldeni (ami mégegyszer, init-service irány, és NEM service-init irány). Másra nincs szükség.

Egyébként szvsz a legundorítóbb dolog a journalctl, egy fos az egész, olvashatatlan a kimenete, képtelenség kihámozni az üzeneteiből, hogy mi a fasz történt, ráadásul tök felesleges redundancia, mert pont erre való a syslog. Ha egy init környezet nagyon akarná tudni, mi a fene folyik egy service-on belül, akkor arra ott az RFC5424, ami rendesen ki lett találva, jól strukturált üzenetekkel (a protokoll sokkal több, mint amit a logokban látsz!).

Ha a jóval több infó a cél, simán nézhetné azt, nem kell ehhez újra feltalálni a spanyolviaszt, csak sokkal szarabbul, ahogy a systemd tette. (Ja, és a syslog küldéshez még plusz lib sem kell, POSIX szabvány, tehát nincs plusz supply-chain attack felület, nincs extra függőség, az OpenSSH egyébként is használja, és mivel egyirányú csak-küldés kommunikáció, azon keresztül egész biztos nem lehet backdoor-t telepíteni, hacsak nem magát a libc-t támadják, ami egy ici-picit macerásabb, mint egy 3rd party libet támadni.)

Továbbra is fenntartom, hogy a tényleges probléma itt az, hogy a systemd egy hulladék, pocsékul megtervezett bloated fos. Nekem soha semmi bajom nem volt a SysV init-tel, mindig tette szépen a dolgát, tök felesleges volt lecserélni csak mert. Én eddig még semmi előnyét nem tapasztaltam meg a systemd-nek, csak a problémáiba futottam bele a hétköznapi használat során.