( SzBlackY | 2019. 10. 06., v – 18:09 )

Az init rendszerek adhatnak erre backendet, a loggerek meg erre csatlakozhatnak.

Tehát (ahogy lentebb a kolléga is említette), kvázi köteleznél minden init rendszer és logrendszer írót, hogy tartsanak be egy API-t, amit valaki valahol kitalált, és jó esetben használható is és nem hátráltat senkit.

Nyugodtan lehet olyat is írni, ami több initrendszerét is ismeri.

Oks, mégse, mindenki írja meg az összes init rendszerhez a saját illesztőjét (márha az adott init rendszer ad megfelelő funkcionalitást ehhez), tehát legyen n*k protokollunk.

A sysloghoz sem kell a daemonokon módosítani, tehát ez nem érv a systemd mellett.

Láthatóan kell, mert nagyon sok daemon simán stderr-re logol, van, ami saját fájlba saját formátummal (<- ezzel egyébként sajnos még mindig nem kezdtünk semmit :( ) és véletlenül sem a syslogba.

Tehát ahhoz, hogy a systemd egy monolitikus, szűrhető/kereshető logging szolgáltatást nyújtson, ahhoz kell pl. a logind, vagy a resolved?

Resolved speciel semmihez nem _kell_, opcionális (mint oly sok minden más, amit kifogásolsz). A logind pedig közvetlenül nem vesz részt a logolásban, viszont a logba bekerülnek olyan adatok, amiknek a létrehozásáért a logind felel (pl. session id).
Minden egyes szerinted felesleges összegyúrásnál ott lenne, hogy vagy funkciót vesztesz nélküle, vagy csak API-t adna, amit mindenki vagy implementál, vagy nem (speciel itt van egy szép lista: https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityA…, a loggerhez a Service Bus API getUnitByPID() hívása az, amit minimum implementálnia kellene mindenkinek - természetesen mögötte az összes logikával, ami kell ahhoz, hogy egy random PID-hez tudj mondani egy unit-ot)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)