( SzBlackY | 2014. 09. 17., sze – 20:14 )

Továbbra is: EGY sor a service konfigjában, hogy mit kezdjen vele a systemd, ha lehalna. A Fedora-s javaslat az, hogy ha csak nincs nyomós érv (pl. hogy gondot okozhat az automatikus újraindítás) ellene, ez minden szolgáltatásnál legyen on-failure (hogy mi számít failure-nek, az a service típusától függ, man systemd.unit), a default a ne csináljon semmit.

nem tudom h a systemd mitcsinal akkor ha veglegesen ledoglik egy process.

A szolgáltatás típusától is függ, de többnyire: amint a szolgáltatáshoz tartozó cgroup kiürül (ez alól ugye nincs menekvés, ezzel mindig lehet követni őket), akkor hallottnak tekinti a szolgáltatást (és itt jön képbe a Restart opció értéke...)

virtualis kornyezetben ez nem gond

Virtuális környezetben már nem kell az erőforrásokkal/biztonsággal játszani? Megyek is virtualizálni... Az erőforrás-kezelés itt a rendszeren belül érvényes, vagyis hogy tudd szabályozni, hogy melyik process mit művelhet, mennyi memóriát és cpu-t vihet el - aminek virtuális környezetben is van értelme, mert virtuális környezetben is lehetnek egy-egy szolgáltatást érintő kiugró tüskék, ami közben a többinek is működnie kell. man systemd.resource-control

ezt most nem ertem. mar most a systemd-vel allitod a host nevet

Ez gondolom a szétbarmolt init-re vonatkozott: igen, disztrónként szét van barmolva. Nincs két ugyanolyan init script a disztrók között (pedig 95%-ban ugyanazokat a csomagokat szállítják...), emiatt pedig az összes beállító rendszer (amivel mondjuk egy Bind-ot chroot-ba zársz [RHEL: /etc/sysconfig/named ROOTDIR változója, Debian: /etc/default/bind9 az OPTIONS-ben meg tudsz adni új paramétereket a bind-nak, aztán a manból kikeresheted, hogy melyik a chroot]) disztó-specifikus lett. Egyelőre a systemd-nél ez nincs meg.

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