Co odróżnia systemd od innych systemów inicjujących?

Nie jest to do końca oficjalne, ale wygląda na to, że systemd zbliża się do Debiana i po przeczytaniu gorącej dyskusji na liście dyskusyjnej na temat tej decyzji, jestem ciekawy polaryzacyjnej natury systemd wśród użytkowników Linuksa. Używam systemów Debian (sysvinit) i Gentoo (OpenRC) i nie wiem nic konkretnego o systemd, choć wygląda na to, że nadejdzie moja droga.

Widziałem podobne pytanie zadające zalety i wady systemd kontra upstart, ale minęły 3 lata od opublikowania tego pytania i jestem pewien, że w tamtym czasie wszystko się zmieniło.

Moje pytanie brzmi: jak systemd wypada w porównaniu z innymi systemami init?

• Co go wyróżnia - co może zrobić, że inne systemy inicjujące nie mogą?
• Czy jest coś do stracenia, przechodząc na inny system inicjacji?
• Jak administracja systemd różni się od innych?

Prawdopodobnie wszystko, co chcesz wiedzieć, znajduje się tutaj na stronach „ Debate Init System To Use ”, które projekt Debian zebrał, podejmując decyzję, z którym systemem wybrać. Na tej stronie znajduje się osobny link do każdego wyboru initsystems.

• Rozpoczęcie debaty w nowym systemie
• Debata initsystem systemd

Dla podkładu na Systemd ta strona zawiera prawie wszystko, co trzeba wiedzieć, aby zacząć z nim korzystać, RHEL7: Jak zacząć z Systemd .

Dodatkowe zasoby, które okazały się pomocne w lepszym zrozumieniu 2 głównych wyborów, przeczytałbym również strony Wikipedii dotyczące odpowiednich technologii:

• https://en.wikipedia.org/wiki/Upstart
• https://en.wikipedia.org/wiki/Systemd

Projekt Gentoo utrzymuje także ładne porównanie niektórych kluczowych funkcji w różnych systemach initsytems:

• Dyskusja: Porównanie systemów init

Moje zdanie na twoje pytania

P # 1: Jak systemd wypada w porównaniu z innymi systemami init?

To bardzo trudne pytanie, na które należy odpowiedzieć w odpowiedzi SE, więc wolałbym skorzystać z różnych źródeł, o których wspomniałem powyżej. Powiem to jednak. Czytając wiele artykułów na temat systemdalternatyw, stara się odnieść do wielu aspektów tego, czego brakowało w poprzednich narzędziach używanych do uruchamiania usług w systemach Linux. Ma bardzo dobrze przemyślaną konstrukcję i stara się zapewnić go w bardzo modułowy sposób.

IMO powiedziałbym, że porównuje bardzo korzystnie zarówno pod względem wysiłku w jego projektowaniu, wykonaniu tego projektu, jak i przyjęcia go przez kilka większych dystrybucji Linuksa.

P # 2: Co go wyróżnia - co może zrobić, że inne systemy inicjujące nie mogą?

Jest wiele rzeczy, które sytemdmożna zrobić, których inne systemy nie mogą. Prawdopodobnie 3 z jego najsilniejszych cech to:

1. Wycięcie lasu
2. Ograniczanie zasobów
3. Radzenie sobie z demonami, które rozwidlają się

1. logowanie

Na froncie logowania systemdwprowadzono nowy system rejestrowania o nazwie „Journal”, usługa nazywa się systemd-journald.service. To jest jego własny temat, więcej na ten temat możesz przeczytać tutaj w tym artykule zatytułowanym: Przedstawiamy czasopismo . Oto przykład logującego się użytkownika „harald”.

_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500

2 i 3. Ograniczanie zasobów i demony, które rozwidlają się

systemdużywa tutaj nowatorskiego podejścia polegającego cgroupsna ograniczeniu i ograniczeniu zasobów usług wymagających rozwidlenia lub ograniczenia dostępu do zasobów.

fragment

Systemd ma bardzo sprytne rozwiązanie problemu śledzenia demonów, które rozwidlają się, co przypadkowo zdarza się jednocześnie obsługiwać ograniczanie zasobów. Tam gdzie Upstart używa ptrace do oglądania rozwidlenia, systemd uruchamia każdego demona w grupie kontrolnej (wymaga Linuksa 2.6.24 lub nowszej), z której nie może uciec przy żadnej ilości rozwidlenia. Pozwala to na łatwe ograniczanie zasobów, zarówno dla demonów rozwidlających, jak i nie rozwidlających, ponieważ grupy kontrolne zostały stworzone dla tego rodzaju rzeczy.

Źródło: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

P # 3: Czy jest coś do stracenia, przechodząc na inny system inicjacji?

Prawdopodobnie największym zastrzeżeniem do przejścia na systemed over Upstart lub sysV init jest konieczność uwzględnienia wielu nowych złożoności. Systemd ma wiele ruchomych części i jest niezwykle bogaty w funkcje, a dzięki tym dodatkowym funkcjom prawdopodobnie spędzisz sporo czasu na zrozumieniu, jak to wszystko działa.

P # 4: Jak administruje systemd na tle innych?

Jak stwierdzono w mojej powyższej odpowiedzi na pytanie nr 3. Powtórzę tutaj jeszcze raz. Tam, gdzie sysV init był dość trywialny, aby nauczyć się zarządzać i nawigować w ciągu kilku godzin lub dni, Upstart prawdopodobnie zajmie ci tydzień lub dłużej, aby przyśpieszyć, podczas gdy systemd prawdopodobnie zajmie ci dużo dłużej, przewiduję, że wezmę kilka tygodni, aby zdobyć wystarczającą pobieżną wiedzę na ten temat, gdzie będę w stanie zarówno tworzyć własne .servicepliki, jak i zatrzymywać / uruchamiać usługi z taką samą łatwością, jaką cieszę się teraz z sysV init.

Referencje

• Proces uruchamiania systemu Linux
• Poważne problemy z syslog?
• strona podręcznika systemd-journald.service