SysV eseten volt egy inditoscript, azt elinditottad es szolt. Azon belul kb azt csinaltal, amit akartal, ha az inditott service elokeszitest igenyelt, akkor azt, ha a service tobb darabbol allt, akkor tobb demont inditottam ugyanazon service keretein belul. Ezt most mar csak mindenfele wrapper scriptekkel lehet megtenni, ami valojaban semmivel sem jobb, mint a SysV scriptek voltak, csak van az egesz felett egy teljesen felesleges reteg. Az upstart meg az OpenRC megoldotta jol a fuggosegkezelest meg a szervizkovetest, cserebe pontosabb es jobb hibauzeneteket kaptam amikor a szerviz ugy dontott, megse indul el. Most meg lehet nyomozni a korlatozott tudasu journalctl-bol, ami - ahogy eszrevettem - mintha csak az stderr-t logolna, a stdout-ot nem, vagy forditva. Pedig sokszor mindket kimeneten van info.
Ugyanigy problema a forkolos demonok kezelese. A SystemD azt erolteti, hogy mindenkeppen eloterben futtasd az alkalmazast, es majd o lekoveti a folyamatot. Aztan ha ez valahogy megse jon ossze, akkor kinlodhatsz, mire reseteled a demon statuszat a SystemD allapottarolojaban, cserebe elvesztve az infokat. A forkolos szervizeknel legalabb biztos lehettem abban, hogy valahova biztos tesz egy logfajlt, ezeknel az uj, eloterben futo szervizeknel meg lehet talalgatni, hogy hova mennek a logok. Nincs meg a disztrokeszitokon/fejlesztokon az a kenyszer, hogy ertelmesen kezeljek a logokat, "fossuk ki az egeszet stdout-ra, aztan majd az uzemelteto sziv ezzel az egesszel".
Azt erzem, hogy a SystemD sokszor inkabb utban van a hibakereses/menedzseles soran, mintsem segitene a munkat. A SysV alapu init rendszerek legalabb probaltak nem utban lenni, ha nem is segitettek.
--
Blog | @hron84
Üzemeltető macik