( SzBlackY | 2014. 08. 16., szo – 15:26 )

És ha én olyan hülye vagyok, hogy csak a grepet akarom használni?

Feladathoz eszközt... egyébként meg... Unix alapelv: pipe. journalctl | grep...

Vagy ha én FreeBSD-n akarom használni, mert annyira tetszik?

Semmi akadálya, portold az összes kernel feature-t, amit eddig senki nem használt, mert nem POSIX, viszont amitől használható lett a systemd...

Ja, még egy, ami eszembe jutott, cron is van benne, de persze nem tudja az összes funkcionalitást, amit az eredeti ... És kérdem én, ez minek?

Viszont cserébe garantáltan ugyanúgy fogja indítani a szolgáltatásokat, mint ahogy az init teszi - mert egész pontosan ő fogja tenni. Szemben a kártyavár: ott van a Monit, nagyon jó program, hasznos (az ilyen aktív monitorozást spec. hiányolom is a systemd-ből), FAQ: inkább kapcsold ki az init.d-vel indított szolgáltatásokat és hagyd, hogy a monit indítsa őket. Vagyis: egy technikai deficit miatt (gyk.: nincs összefüggés processz és service között) bizonyíthatóan lehetetlen race-free módon megcsinálni valamit, ezért a megoldás, hogy kihúzzuk azt a rendszert, amivel mindenki számol (és amiért mindenki oly nagyon sír - a SysV-t) és helyettesítjük egy kicsit mással. Systemd mellé (és le merem fogadni, hogy nemsokára lesz rá projekt) egyszerűen lehetne ilyen monitorozó ügynököt írni: lefuttatja a tesztet, ha nem jött be, D-Bus-on szól a PID 1-nek. Ezért kell árukapcsolás: feleslegesen duplikált (és karbantartott, auditált stb.) kódok helyett moduláris, de egy ernyő alá tartozó rendszermenedzser.

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