On Sat, Dec 31, 2016 at 19:41:31 +0100, Krzysztof Szwaba wrote: > Czy aktualnie wszystkie usługi posiadają w PLD pełne wsparcie > dla systemd ?
Co rozumiesz przez "pełne"? 1. W rc-scripts wiele usług nie miało w ogóle bądź miało jakieś ułomne, czasem w ogóle niedziałające skrypty. 2. Systemd obsługuje skrypty SysV, więc wsparcie w PLD dla systemd jest NADZBIOREM rc-scripts. O ile skrypt SysV nie jest walnięty. 3. Założenie projektowe systemd jest takie, że unity przychodzą z upstreamu, a nie są generowane przez dystrybucje - w PLD pakujemy te pliki, ale oczywiście upstream może mieć także walnięte. W takiej jednak sytuacji istnieje szansa, że zgłosili to ludzie z innych dystrybucji więc znowu - rc-scripts jest podrzędne względem systemd, także w PLD. Mówiąc krótko: jeżeli coś nie działa w systemd, to _prawdopodobnie_ w rc-scripts też nie działało. Tutaj nie powiem już z taką stanowczością, bo istnieje szansa, że coś w rc-scripts działało przypadkiem, mimo łamania przez skrypt LSB czy wszelkich innych standardów. Jeżeli pytasz natomiast o _natywne_ wsparcie dla systemd - odpowiem, że nie ma to znaczenia. Oczywiście, jakieś foobard sprzed 23 lat nie będzie zapewne miało .service, bo po prostu nikt tego nie używa. Np. http://git.pld-linux.org/packages/tacacs.git Rozwijając jeszcze odpowiedź, już z pewnością poza to, o co pytasz - jeszcze dużo gnojówki z Wiejskiej wyleją, zanim same usługi będą miały pełne wsparcie DLA systemd (w tę stronę). W systemd, poza nadrzędnym supervisorem i journalem, o którym wiele niedorzeczności już powiedziano, masz takie rzeczy jak watchdoga dla serwisów (sd_notify) czy nowe struktury do logowania (zdecydowanie to bardziej rozbudowane, niż facility i level, a do tego katalogi komunikatów). Zanim oprogramowanie przesiądzie się z tych swoich furmanek (samodzielne forkowanie/demonizacja procesów, pliki PID-ów) do mercedesa klasy S (bo mniej więcej taka jest różnica pomiędzy rc-scripts a systemd), nie będziesz chyba czekał z boku z widłami? Pominę już tutaj takie oczywiste rzeczy jak kontrola zasobów na poziomie unitów (MemoryLimit samo włącza accouting, nasz OOTB nice level, scheduling policy, ionice), dropowanie uprawnień, ograniczanie dostępu do katalogów, separacja sieci itp. Chyba w kernelu 4.10 doszła możliwość podpinania BPF-a pod grupy - czyli zaraz będziesz mógł budować swoistego firewalla dla aplikacji. Jak sobie wyobrażasz wykorzystanie tego mechanizmu bez systemd? A w ogóle w jaki sposób dzisiaj nadajesz określonemu użytkownikowi prawa do zarządzania określonymi usługami? - czy z roota pracujesz? Zobacz sobie działanie systemd-nspawn --ephemeral na btrfsie. Na prawdę trzeba mieć BARDZO DOBRY powód, żeby NIE korzystać z systemd. Jeżeli takiego powodu nie znasz, to o rc-scripts spokojnie zapomnij. Nawt jeżeli natrafisz na coś niedziałającego, to szybciej się uwiniesz z naprawą pod systemd, niż gdybyś marnował czas na rzeźbienie skryptów. A i tak od wszelkich wannabe i innego chaxiorstwa usłyszysz, że w systemd chodzi o szybsze uruchamianie systemu;) -- Tomasz Pala <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
