Większą zmianą, która jest dostarczana z Ubuntu 15.04, jest przejście z upstart na systemd jako domyślną opcję zarządzania uruchomieniem i uruchomieniem usługi systemowej.
Czy ktoś mógłby odpowiednio wyjaśnić nietechnicznemu użytkownikowi, w jaki sposób i jeśli w ogóle ma to wpływ na nas? I dlaczego to jest ważne?
Użytkownicy Laika z założenia nie powinni zauważać żadnych zmian. To system inicjujący, a nie coś, z czym użytkownicy tradycyjnie wchodzą w interakcje. Powinien całkowicie zastąpić funkcjonalność zapewnianą przez Upstart - i zrobić kilka dodatkowych rzeczy - ale tylko nietechniczny użytkownik zobaczy to wtedy, gdy coś pójdzie nie tak.
Użytkownicy, sysadmini i programiści, którzy aktywnie korzystają z Upstart i rozwijają się, to ludzie, którzy muszą zająć się różnymi sprawami. Na Wiki Ubuntu znajduje się dokument migracji, który pomaga programistom konwertować skrypty init, ale użytkownicy i sysops mogą kontynuować korzystanie z Upstart, pozostając przy wersji 14.04 (która jest obsługiwana do 2019 r.).
Powód i uzasadnienie zmiany tak naprawdę nie pochodziło od Ubuntu. Canonical był wystarczająco zadowolony z Upstart (ich projekt), ale wielu użytkowników Debiana chciało przejść do nowoczesnego silnika init, aby uzyskać lepszą współbieżność podczas uruchamiania i lepszą funkcjonalność monitorowania we wszystkich usługach.
Oznaczało to walkę między różnymi opcjami (uzasadnienia) i systemd, w końcu wygrał.
Canonical współpracował z Debianem, ponieważ jest najłatwiejszy i prawdopodobnie najlepszy. Porzucają projekt i nie walczą w górę. To także zbliża nas do innych dystrybucji (Red Hat, Fedora itp.), Które również przechodzą na systemd. Większa koncentracja i mniejsze powielanie wysiłków.
tl; dr Dla osoby nietechnicznej nie powinno to mieć żadnego wpływu na ciebie. Dla Ubuntu powinno to oznaczać mniej pracy i lepszy system inicjujący.
Czy ktoś mógłby odpowiednio wyjaśnić nietechnicznemu użytkownikowi, w jaki sposób i jeśli w ogóle ma to wpływ na nas?
Teoretycznie nie powinno to wpływać na nietechnicznego użytkownika końcowego, który nie angażuje się w drobiazgowe działanie tego systemu. W praktyce zobaczysz wiele rzeczy.
Oto niepełna lista:
init+ rcsą pogryzione przez fakt, że systemd jest tylko wstecznie kompatybilny z Systemem 5 rc. Podobnie jak upstart, a nawet większość innych systemów, profesor i zapewnia, brak kompatybilności wstecznej z Systemem 5 initi jego plikiem konfiguracyjnym /etc/inittab.Tak więc osoby, które postępowały zgodnie z radą 30-letnich osób doradzających „Cóż, możesz to po prostu zmienić na /etc/inittab…” lub osoby korzystające z oprogramowania, które zastosowało się do tej rady, ma teraz oprogramowanie, które nie zaczyna się od bootstrapu. Przykład: https://unix.stackexchange.com/a/196197/5132
shutdownpolecenia systemd , podobnie jak w przypadku poprzednich shutdownpoleceń. Oprócz tego, że nazywa się to trybem ratunkowym w żargonie systemowym, tryb ratunkowy nie jest uważany za stan zamknięcia w światopoglądzie systemowym. Jest uważany za działający . shutdown nowwyłączy urządzenie. To systemctl rescueby dotrzeć do trybu single-user w Systemd świata. Dalsza lektura: https://unix.stackexchange.com/a/196471/5132--useropcją systemctl. Nie dotyczy to jeszcze Ubuntu. Upstart i systemd różnią się znacznie w tym obszarze, a Ubuntu w wersji 15 nadal korzysta z inicjalizatora sesji upstart zamiast sesji systemowej dla instancji użytkownika . Na przykład https://superuser.com/a/860598/38062 nie będzie obowiązywał. ☺Jak już zauważyli inni, teoretycznie nie powinno to wpływać na nietechnicznego użytkownika końcowego - i teoretycznie nie ma różnicy między teorią a praktyką, ale w praktyce jest.
Myślę, że kilka opublikowanych tutaj rzeczy wymaga wyjaśnienia:
To system inicjujący, a nie coś, z czym użytkownicy tradycyjnie wchodzą w interakcje.
Tak było w przypadku SysV init i Upstart, ale już tak nie jest w przypadku systemd. Robi wiele rzeczy, z którymi użytkownicy tradycyjnie wchodzą w interakcje:
Powinien całkowicie zastąpić funkcjonalność zapewnianą przez Upstart - i zrobić kilka dodatkowych rzeczy
Dwie rzeczy do wyjaśnienia - po pierwsze o całkowitym zastąpieniu Upstart:
Jednym z problemów, które ludzie mają z systemd, jest to, że nie uruchamia on skryptów inicjujących SysV. Jest więc jeden przykład, że nie zastępuje całkowicie funkcjonalności zapewnianej przez Upstart.
Jest to coś, na czym moglibyśmy polegać przez ponad 30 lat i tradycyjnie pisałeś skrypty inicjujące SysV dla maksymalnej przenośności bez powtarzania się (pisząc wiele wersji tych samych skryptów), co nie jest już prawdą.
Nie powinno to stanowić problemu przy korzystaniu wyłącznie z pakietów z oficjalnych repozytoriów, ponieważ przypuszczalnie wszystkie pakiety, które miały kiedyś skrypty init SysV lub Upstart, musiałyby zostać przepisane, zanim zostaną spakowane.
Będzie to problem tylko dla osób, które korzystają z oprogramowania firm trzecich lub niestandardowych, które mają swoje skrypty init napisane dla SysV init lub Upstart, a one będą musiały przepisać skrypty init przed aktualizacją do systemu za pomocą systemd (lub uzyskać zainstalowany upstart, który jest również opcją , lub migruj do systemu, który nie używa systemd).
Istnieje systemd-sysv-generator, który ma automatycznie tłumaczyć skrypty inicjujące SysV na skrypty systemowe, ale jest kilka błędów i długa lista wyraźnych niezgodności .
Teraz drugie wyjaśnienie - o tych kilku dodatkowych rzeczach:
Te „kilka dodatkowych rzeczy”, które systemd zamierza omówić - według Perspektywy dla systemd - Co zostało osiągnięte i Co dalej przed prezentacją Lennarta Poetteringa w 2014 roku na GNOME.asia - są następujące:
Wracając do: „To system inicjujący, a nie coś, z czym użytkownicy tradycyjnie wchodzą w interakcje”. - należy zauważyć, że system inicjujący jest tylko jedną pozycją na tej liście.
I na koniec ostatnia rzecz, którą chciałbym skomentować:
[T] tylko raz użytkownik nietechniczny zobaczy, że dzieje się tak, gdy coś pójdzie nie tak.
Co za ulga. :)
Najważniejsze zmiany dla użytkowników końcowych (innych niż same skrypty) to uruchamianie i zatrzymywanie usług oraz używanie poleceń takich jak:
które nie działają już zgodnie z oczekiwaniami. Na przykład nohupjest poleceniem POSIX, aby upewnić się, że proces będzie kontynuowany po wylogowaniu z sesji. To już nie działa na systemd. Również programy takie jak screeni tmuxmuszą być wywoływane w specjalny sposób, w przeciwnym razie procesy, które uruchamiasz za ich pomocą, zostaną zabite (chociaż nie zabicie tych procesów jest zwykle głównym powodem uruchomienia screena lub tmuxa).
To nie jest błąd, to wybór projektowy, więc prawdopodobnie nie zostanie naprawiony w przyszłości. Oto, co Lennart Poettering powiedział na ten temat:
Moim zdaniem, w rzeczywistości UNIX był dość dziwny, że domyślnie pozwalał na swobodny dostęp dowolnego kodu użytkownika po wylogowaniu. Od wieków jest dyskutowane przez wiele osób z OS, że powinno to być możliwe, ale z pewnością nie powinno być domyślnym, ale nikt nie odważył się dotąd przesunąć przełącznika, aby zmienić go z domyślnego na opcję. Brak czyszczenia sesji użytkownika po wylogowaniu jest nie tylko brzydki i nieco hackerski, ale także stanowi problem bezpieczeństwa. systemd 230 teraz w końcu przestawił przełącznik i wreszcie domyślnie czyści wszystko poprawnie po wylogowaniu użytkownika.
Aby uzyskać więcej informacji zobacz:
screenscreensystemd-run --user --scope screen(Uwaga: zachowanie „upstart” powyżej jest naprawdę wszystkim oprócz systemd, nie jest to specyficzne dla upstart)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Zobacz moją odpowiedź na Jakie są zalety / wady Upstart i systemd ?, aby uzyskać więcej informacji, które są poza zakresem tego pytania.)
Istnieje również duża różnica w obsłudze dzienników, ponieważ w przeciwieństwie do tradycji uniksowej dzienniki systemd są przechowywane w plikach binarnych w niestandardowym formacie, więc zamiast:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
musisz użyć specjalnych poleceń, aby uzyskać dostęp do dzienników:
sudo journalctl -u foo
sudo journalctl -u foo -f
Wprowadzenie systemud najpierw do Debiana, a później do Ubuntu nie obyło się bez kontrowersji i ogromnego sprzeciwu, jak wiadomo każdemu, kto napisał jeden z następujących artykułów:
Oficjalne stanowisko Debian na Systemd i otrzymaną kontrowersje doprowadziły do deklaracji Exodus w 2014 roku i zakończył się rezygnacji Iana Jacksona .
Powstały inicjatywy Init Freedom , Without-Systemd.org i Systemd-Free.org , z dużą ilością dyskusji w Hacker News .