( uid_194 | 2014. 10. 21., k – 08:27 )

Nem a környezetednek kell tudnia, hogy neked mire van szükséged, hanem neked magadnak.

Az egy dolog, hogy en tudom, mire van szuksegem. Az egy teljesen masik dolog, hogy ezt nekem kell *minden* init scriptben leellenoriznem.

Olyan dolgot vártok el a sysvinit-től, ami by design nincs benne, amit az azt használó scripteknek kell tudnia.

Nem varom el a sysvinittol. Tudom, hogy nem tudja, es nem is tudhatja. En azt allitom, hogy a systemd azert (is) jobb, mert tudja ezt. Tobbet nyujt, kenyelmesebben, nekem. Ettol nem lesz rossz, azert mert okosabb.

Egyébként miért lenne minden scriptben pl. a "van-e hálózat?" újraimplementálva?

Mert minden distron maskepp van egy kicsit, es a legtobb upstream pedig nem koveti mindet, illetve probal olyat csinalni, ami portabilisabb. Upstream tobbnyire distrora bizza, a distro maintainerek meg sajat szajuk ize szerint csinaljak, igy ket distro kozott az init script elegge mas tud lenni.

Maximum azért, mert az adott disztró összeállítója nem csinálta meg egy közös eljáráskönyvtárban, vagy ha megcsinálta, az adott initscript elkövetője nem használja azt.

Welcome to real life.

Sőt, a scriptek futtatása nem szól arról, hogy valamit életben kell tartani, ha kidől - erre az inittab való.

Az inittab az egy formedveny, egyreszt. Masreszt ha ez igy lenne, akkor nem szolt volna jopar cikk tiz evvel ezelott is olyan megoldasokrol, amik eletben tartottak a kulonbozo serviceket (pl daemontools).

Mondok egy peldat! Vegyuk a syslog-ng -t, ami ugye egy loggolo alkalmazas, es kene neki halozat, hogy tudjon a kozpontba kuldeni logokat. Tehat belerakok az init scriptbe egy Required-Start: $network sort. Igy a sysvinitre epulo dependencia kezelo rendszer be tudja kotni a megfelelo helyre. Ez eddig jo. Amde ezen kivul meg kell pidfile kezeles, es jo lenne, ha nem indulnank el ketszer - ennek kezelese nemileg races, bar az utobbi idoben sikerult egesz korrektul megcsinalni, es nem hasal el (lasd Debianon /etc/init.d/syslog-ng syslog_ng_wait() fuggvenyet). Ezen kivul ott van ugye a start-stop-daemon hivas, ami szinten megnezi, el-e meg masik syslog-ng, a biztonsag kedveert. Ez az egesz azert elegge torekeny. Arrol nem is beszelve, hogy systemd nelkul egy regebbi Linuxot vagy egy haklisabb OS-t siman be lehet akasztani boot kozben azzal, hogy rengeteget logol az ember /dev/log -ra, mert a syslogd keson indul, es a /dev/log betelik, es blokkol a syslog() (workaroundoltunk mar ilyen hibat anno!).

Ezzel szemben a systemd unit file 15 soros, ko egyszeru, es a systemd megoldja az osszes problemat, messze jobban, mint a sysvinit. Azert, mert a sysvinit nem tudja, mert buta, es nincs meg neki annyi informacio, mint a systemdnel. A systemd latja az egesz rendszert, az osszefuggeseket, az osszes processt es unitot egyszerre, es ezek alapjan sokkal hatekonyabban tud segiteni nekem. A sysvinittel ezt nem lehet megcsinalni, legfeljebb imitalni, ami elobb-utobb el fog torni.

Es igen, a sysvinit nem arrol szol, hogy mi mitol fugg. Es ez baj. Lehet, hogy 20 eve nem volt problema, de ma, amikor lenyegesen komplexebb rendszereket epit az ember, szeretne azt egyszerubben es megbizhatobban csinalni. A sysvinittel ez eselytelen.

--
|8]