nem lettem, csak kevésbé kedvelem az olyen megállapításokat, hogy mánmegintszarasystemd, mert aztán jön majd pl mispelled gandzsa barátunk, és felírja a listájára, hogy hát factually szar a systemd, hát bele van írva a Zinternetbe. Miközben meg nem, valaki tudatosan bekapcsolt egy featuret. Azért van az egész "tényleg működik systemd nélküli", cseszés, mert neki a dolga a futtató környezet. Ez a típusú "hiba" nem új, és nem is systemd specifikus, előtte a "miafaszért nem fut ez cronból, mikor elindítva igen" volt a sláger, csak unlike a cron, a systemd legalább ad eszközt, amivel tudod úgy tesztelni, mintha ő indítaná. A munin fejlesztők használják is, nem is trivi, hogy miért futott le munin-runból, a kódot olvasva nem kellett volna.
A jobb hibaüzenet valóban jogos igény, és ez a systemdnél valóban tud vackos lenni, de ebben az esetben -- is, ez máskor is jellemző mint -- az van, amennyire egy gyors kód olvasás , meg common sense alapján látom, hogy egy rendszer featuret konfigurál, nevezetesen egyszerűen a megfelelő paraméterekkel mountolja be az adott könyvtárat az adott processnek. Ebből meg következik, hogy a systemd nem igazán tudja logolni. A rendszer meg alapvetően baszik az fs perm denyokat logolni, erről nem a systemd tehet. Persze cserébe, ha nem ezt csinálná, hanem emiatt keresztülvinné valami saját szolgáltatásán, akkor meg az lenne a baj, hogy miért csinálja ezt is.
És persze ilyenkor a standard eszközökkel lehetne is nyomozni, írtam is, hogy ott az audit alrendszer, azt meg lehetne kérni, hogy legyen kedves.
És az is igaz, hogy ilyesmit általában szebben lehet csinálni mondjuk selinux policyval, többekközött azért, mert jobban logol. Csakhát az egyrészt több munka, másrészt meg unlike systemd, az még nem defacto standard, mert a világ egy jó fele ugye apparmort használ, kétszer dolgozni meg nem szeret senki.