( KeeF | 2014. 10. 22., sze – 01:07 )

arrafele probalok haladni, hogy az alkalmazas egyebkent is lekezeli a hibakat/fuggosegeket. attol most talan tekintsunk el, hogy jobban-rosszabul oldjak meg az alkalmazasok ezt. az init-rendszernek, ide ertem a systemd configjat es a sysvinit scriptjeit is, csak a nagyon alap dolgokat kell mindenkeppen ellenorizni. az hogy az adott port-ra lehet-e bindelni, egyaltalan nem az init/systemd/akarmi gondja. szinten nem az init gondja az alkalmazas logolasaval foglalkozni, hogy eppen hogyan kozli veled oldja meg az alkalmazas: stderr, logfile stb.

az alkalmazasnak nem kell atfogo kepet kapnia. futnia kell, ahogy a program iroi megalmodtak. ehhez szuksegesek/vannak jogai amikkel el tudja donteni, hogy fog-e tudni futni rendesen ill. detektalja a hibakat. (a tuzfal nagyton rossz pelda: annak eppenhogy minden alkalmazastol/service-tol fuggetlenul is kell tudnia mukodni)

eleg nagy problema, ha az init-rendszerre tamaszkodik egy alkalmazas. van esetleg a systemd-nek valamilyen interface-e amin az alkalmazas le tudja kerdezni pl. a halozat allapotat? ha nincs, akkor az alkalmazasnak maganak kell kideritenie, hogy tud-e bindelni az adott interface adott portjara. (leragadtam ennel a port-kerdesnel, de jobb pelda hirtelen nem jut eszembe.)

sorrendiseg vs. fuggoseg. ugy latom mashol is eleg sokat veszik elo ezt az ervet a systemd mellett. az en szempontombol teljesen mindegy a ketto. pl.: 3 service, egymasra epulnek, fuggoseg van. fuggoseg-kezelessel: az 1. fut, a 2. nem indul hiba miatt, igy a 3. sem fog. sorrendnel: a fentiek miatt a service-ok ugysem fognak elindulni ha a fuggoseguk nem indult el elobb, mert ellenorzik a blablabla... nem igazan jon ki a kulonbseg. raadasul meg mukodik is mint latjuk.