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.
Ha előkészítés/lebontás kell a service-nek, arra használható akárhány ExecStartPre/ExecStartPost. Ha egy service több démonból állt és azokat nem egy démon indítgatja, akkor az nem egy service, hanem két külön service, köztük valamilyen irányú függőséggel.
csak van az egesz felett egy teljesen felesleges reteg.
Leszámítva a rengeteg extra funkcionalitást (lásd fenn: biztonsági beállítások, erőforrás-menedzsment, process-menedzsment stb.), amit még kapsz.
mintha csak az stderr-t logolna, a stdout-ot nem, vagy forditva
Nézz szét az systemd-system.conf-ban (DefaultStandardOutput és DefaultStandardError), gyári beállításon mindkettőt el kéne kapnia. Nem lehet, hogy a unit valami shell scriptet indít, ami elnyeli vagy service szinten felülírod (StandardOutput=, StandardError=)?
Ugyanigy problema a forkolos demonok kezelese.
Erre van ott a Type=forking service típus (persze ennek feltétele, hogy az előkészítés tényleg az ExecStartPre-be kerüljön és az ExecStart tényleg már a forkoló démont indítsa), az egyetlen feltétele, hogy a PID filet (ha több processt forkol az ExecStart-ban indított process) hozza létre még a kilépés előtt.
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.
Akkor most a systemd-vel van bajod, vagy az indított démonokkal? Meg milyen démon az, ami forkolva indítva fájlba logol, nem-forkolva meg (kötelezően) nem? (azzal mondjuk egyetértek, hogy iszonyat takony egy-egy service upstream unit fájlja)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)