( zeller | 2019. 09. 17., k – 16:26 )

Írtam olyan előnyöket, meg nem csak én, hanem mások is, amik valódi előnyként jelentkeznek a linuxhuszárok initscriptnek nevezett gánykupacaival szemben. Bár azokhoz képest sokszor a "bármi" is csak jobb lehet. De te mindet ignoráltad. Nekem pl. jól jön, hogy egy fostos java-s alkalmazásszervernél az uid/gid/umask egyszerűen, kényelmesen beállítható, nem kell csillió+1 scriptben gányolni, hogy úgy viselkedjen, úgy működjön, úgy hozza létre a fájlokat, ahogy azt elvárom. És szintén előny, hogyha megkérdezem, hogy aktív-e a szolgáltatás, akkor nem n+1 féle módon scriptből gányolva nézi meg, hogy futkorászik-e az adott daemon. Meg előny, hogy tudok olyat csinálni, ami a sysvinit-nél "feltételes respawn"-ként lenne leírható - ha lenne ott ilyen. Meg egyáltalán, tudom kontrollálni a szolgáltatás(ok) automatikus újraindulását... Hogy a dbus-os okosságokról ne is beszéljünk.

"hogy lehetne egy sima skip, egy skip with password, meg egy root shell lehetőség," - Add fel feature request-ként a systemd fejlesztőinek. Komolyan mondom, hiszen ez óriási tömeges igényként jelentkezik - vagy legalábbis te úgy érzed. De tedd hozzá, hogy minden esetben legyen ilyen, akkor is, ha nincs aktív (jelszóval rendelkező/nem zárolt) root user...

Az asszimilálta a mountot az érdekes... A sysvinit-nél nem az initscriptek mélyén volt elrakva a mount...? Ja, hogy standardizálta, és unitként működik?

Nekem szólt, hogy sz@r van a palcsintában, reszeljem ki az fstab-ot. Kireszeltem, és tényleg ennyi volt. Van ugye a nofail mount opció, ami doksi szerint a device hiánya esetén nem ad hibát - meg kéne nézni, hogy tényleg csak akkor engedi tovább, vagy a mountpoint hiánya/fájlrendszer hiánya esetén is.