Aktualizacja 2016
Większość odpowiedzi tutaj ma pięć lat, więc czas na kilka aktualizacji.
Ubuntu używało domyślnie upstartu, ale porzuciło go w zeszłym roku na rzecz systemd - patrz:
Z tego powodu istnieje ciekawy artykuł Systemd dla użytkowników Upstart na wiki Ubuntu - bardzo szczegółowe porównanie między upstart i systemd oraz przewodnik przejścia od upstart do systemd.
(Należy pamiętać, że zgodnie z wiki Ubuntu nadal można domyślnie uruchomić aktualizację na bieżących wersjach Ubuntu, instalując upstart-sysvi działając, sudo update-initramfs -uale biorąc pod uwagę zakres projektu systemowego, nie wiem, jak to działa w praktyce, ani czy systemd jest możliwe do odinstalowania).
Większość informacji w poniższych sekcjach Polecenia i skrypty została zaadaptowana z niektórych przykładów użytych w tym artykule (które są wygodnie licencjonowane, podobnie jak wkłady użytkowników Stack Exchange w ramach licencji Creative Commons Uznanie autorstwa-Na tych samych warunkach 3.0 ).
Oto szybkie porównanie popularnych poleceń i prostych skryptów, szczegółowe wyjaśnienia znajdują się w poniższych sekcjach. Ta odpowiedź porównuje stare zachowanie systemów opartych na Upstart z nowym zachowaniem systemów opartych na systemie, zgodnie z pytaniem, ale należy pamiętać, że polecenia oznaczone jako „Upstart” niekoniecznie są specyficzne dla Upstart - często są to polecenia, które są wspólne dla każdego niesystemowego systemu Linux i Unix.
Polecenia
Uruchamianie su:
- dorobkiewicz:
su
- systemd:
machinectl shell
(patrz sekcja „zamiana komendy su” poniżej)
Ekran biegowy:
- dorobkiewicz:
screen
- systemd:
systemd-run --user --scope screen
(patrz sekcja „Nieoczekiwane zabijanie procesów w tle” poniżej)
Uruchamianie tmux:
- dorobkiewicz:
tmux
- systemd:
systemd-run --user --scope tmux
(patrz sekcja „Nieoczekiwane zabijanie procesów w tle” poniżej)
Rozpoczęcie pracy foo:
- dorobkiewicz:
start foo
- systemd:
systemctl start foo
Zatrzymywanie pracy foo:
- dorobkiewicz:
stop foo
- systemd:
systemctl stop foo
Ponowne uruchamianie zadania foo:
- dorobkiewicz:
restart foo
- systemd:
systemctl restart foo
Oferty pracy:
- dorobkiewicz:
initctl list
- systemd:
systemctl status
Sprawdzanie konfiguracji zadania foo:
- dorobkiewicz:
init-checkconf /etc/init/foo.conf
- systemd:
systemd-analyze verify /lib/systemd/system/foo.service
Wyświetlanie zmiennych środowiskowych zadania:
- dorobkiewicz:
initctl list-env
- systemd:
systemctl show-environment
Ustawianie zmiennej środowiskowej zadania:
- dorobkiewicz:
initctl set-env foo=bar
- systemd:
systemctl set-environment foo=bar
Usuwanie zmiennej środowiskowej zadania:
- dorobkiewicz:
initctl unset-env foo
- systemd:
systemctl unset-environment foo
Kłody
W fazie upstart dzienniki są normalnymi plikami tekstowymi w katalogu / var / log / upstart, więc możesz je przetwarzać jak zwykle:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
W logach systemowych przechowywane są w wewnętrznym formacie binarnym (nie jako pliki tekstowe), więc musisz użyć journalctlpolecenia, aby uzyskać do nich dostęp:
sudo journalctl -u foo
sudo journalctl -u foo -f
Skrypty
Przykładowy skrypt wstępny napisany w /etc/init/foo.conf:
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
Przykładowy skrypt systemowy napisany w /lib/systemd/system/foo.service:
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
zamiana polecenia su
suWymiana polecenie zostało połączone w Systemd w rozkładaną żądanie # 1022:
ponieważ według Lennarta Poetteringa „su to naprawdę zepsuta koncepcja” .
Wyjaśnia, że „możesz używać su i sudo jak poprzednio, ale nie oczekuj, że zadziała w pełni ” .
Oficjalny sposób na suzachowanie podobne do tego jest teraz:
machinectl shell
Zostało to dalej
wyjaśnione przez Lennarta Poetteringa
w dyskusji do wydania # 825:
„No cóż, wiele się na ten temat dyskutuje, ale problem polega na tym, że to, co powinien zrobić su, jest bardzo niejasne. [...] Krótko mówiąc: su jest naprawdę zepsutą koncepcją. Daje ci to rodzaj skorupy i można z niego korzystać, ale nie jest to pełny login i nie należy go mylić z jednym z nich ”. - Lennart Poettering
Zobacz też:
Nieoczekiwane zabicie procesów w tle
Polecenia takie jak:
nie działa 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 pomyłka, to celowa decyzja, więc prawdopodobnie nie zostanie naprawiona 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 wielu lat dyskutuje się wśród wielu osób z OS, że powinno to być możliwe, ale z pewnością nie powinno być domyślnym, ale nikt nie śmiał do tej pory 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:
Koncepcja uruchamiania na wysokim poziomie
W sposób systemd działa wstecz - w zadaniach upstart zaczynają się tak szybko, jak to możliwe, a w zadaniach systemd rozpoczynają się, kiedy muszą. Na koniec dnia te same zadania mogą być uruchomione przez oba systemy i w prawie tej samej kolejności, ale myślicie o tym, patrząc z przeciwnej strony, że tak powiem.
Oto, w jaki sposób wyjaśnia to Systemd for Upstart Users :
Model Upstart dla uruchamiania procesów (zadań) jest oparty na „zachłannym zdarzeniu”, tzn. Wszystkie dostępne zadania, których zdarzenia startowe są uruchamiane, są uruchamiane jak najwcześniej. Podczas rozruchu upstart syntetyzuje niektóre zdarzenia początkowe, takie jak start lub rcS jako „root drzewa”, wczesne usługi zaczynają się na nich, a później usługi uruchamiają się, gdy te pierwsze są uruchomione. Nowe zadanie musi jedynie zainstalować plik konfiguracyjny w / etc / init /, aby stać się aktywnym.
model systemd dla uruchamiania procesów (jednostek) jest „oparty na leniwej zależności”, tzn. jednostka uruchomi się tylko wtedy, gdy i od niej zależy jakaś inna jednostka początkowa. Podczas rozruchu systemd uruchamia „jednostkę główną” (default.target, można zastąpić w grub), która następnie w sposób tranzytowy rozwija się i uruchamia swoje zależności. Nowa jednostka musi dodać się jako zależność jednostki sekwencji rozruchowej (zwykle multi-user.target), aby stać się aktywną.
Wykorzystanie w dystrybucjach
Teraz niektóre najnowsze dane według Wikipedii:
Dystrybucje domyślnie korzystające z upstart:
Dystrybucje domyślnie używające systemd:
(Zobacz Wikipedia , aby uzyskać aktualne informacje)
Dystrybucje nie korzystające ani z Upstart, ani z systemd:
Spór
W przeszłości Proponowano rozwidlenie Debiana, aby uniknąć systemd . Devuan GNU + Linux został stworzony - widelec Debiana bez Systemd (dzięki fpmurphy1 za wskazanie go w komentarzach).
Aby uzyskać więcej informacji na temat tej kontrowersji, zobacz:
Jak wielu z was może już wiedzieć, głosowanie Init GR Debian promowane przez Iana Jacksona nie było przydatne do ochrony dziedzictwa Debiana i jego użytkowników przed lawiną systemową.
Sytuacja ta przewiduje blokadę systemowych zależności, która de facto zagraża wolności rozwoju i ma poważne konsekwencje dla Debiana, jego wyższego i niższego szczebla.
CTTE udało się zamienić zależność i zyskać czas na subtelną instalację systemd nad sysvinit, ale nawet ten proces był wyczerpujący i pełen dramatyzmu. Ostatecznie tydzień temu Ian Jackson zrezygnował. [...]
Rezygnuję ze stanowiska komitetu technicznego ze skutkiem natychmiastowym.
Chociaż ważne jest, aby poglądy 30–40% projektu, które się ze mną zgadzają, były nadal reprezentowane w TC, ja osobiście jestem zdecydowanie zbyt kontrowersyjny w tym miejscu, aby to zrobić. Powinienem odsunąć się na bok, aby ograniczyć zakres personalizacji rozmów na temat zarządzania projektem. [...]
Devuan narodził się z kontrowersji związanych z decyzją o użyciu domyślnego systemu init dla Debiana. Oficjalne stanowisko Debian na Systemd jest pełen twierdzi, że inni zdemaskowana . Zainteresowani czytelnicy mogą kontynuować dyskusję na ten gorący temat w kontrowersji Systemd . Zachęcamy jednak do zachowania chłodu i uprzejmości w głosie. W Devuan jesteśmy bardziej zainteresowani błędnym programowaniem niż oglądaniem się za siebie. [...]
Powstały niektóre strony i artykuły poświęcone systematycznej kontrowersji:
W Hacker News jest wiele interesujących dyskusji:
Podobne tendencje można zaobserwować również w innych dystrybucjach:
Filozofia
upstart podąża za uniksową filozofią DOTADIW - „Zrób jedną rzecz i zrób to dobrze”. Jest to zamiennik tradycyjnego demona init. Nie robi nic poza uruchamianiem i zatrzymywaniem usług. Inne zadania są przekazywane innym specjalistycznym podsystemom.
systemd robi znacznie więcej. Oprócz uruchamiania i zatrzymywania usług zarządza także hasłami, loginami, terminalami, zarządzaniem energią, resetami fabrycznymi, przetwarzaniem logów, punktami montowania systemu plików, obsługą sieci i wiele więcej - niektóre z funkcji można znaleźć w pliku NEWS .
Plany ekspansji
Zgodnie z prezentacją „Perspektywy dla systemd Co zostało osiągnięte” i „Co nas czeka” Lennarta Poetteringa w 2014 roku na GNOME.asia, oto główne cele systemd, obszary, które zostały już uwzględnione i te, które wciąż były w toku:
cele systemowe:
Nasze cele
- Przekształcanie Linuksa z worka bitów w konkurencyjny system operacyjny ogólnego zastosowania.
- Budowanie internetowego systemu operacyjnego nowej generacji Ujednolicanie bezcelowych różnic między dystrybucjami
Przywracanie innowacji do podstawowego systemu operacyjnego
Desktop, Server, Container, Embedded, Mobile, Cloud, Cluster,. . . Te obszary są bliżej siebie niż mogłoby się wydawać
- Zmniejszenie złożoności administratora, niezawodność bez nadzoru
- Wszystko introspekcyjne
- Kluczem jest automatyczne wykrywanie, plug and play
- Naprawiamy rzeczy tam, gdzie są zepsute, nigdy nie nakładaj na nie taśmy
Obszary już objęte:
Co już obejmuje:
system init, rejestrowanie dziennika, zarządzanie logowaniem, zarządzanie urządzeniem, zarządzanie plikami tymczasowymi i lotnymi, rejestracja formatu binarnego, zapisywanie / przywracanie podświetlenia, zapisywanie / przywracanie rfkill, bootchart, readahead, konfiguracja pamięci szyfrowanej, wykrywanie partycji EFI / GPT, maszyna wirtualna / kontener rejestracja, zarządzanie minimalnymi kontenerami, zarządzanie nazwami hostów, zarządzanie ustawieniami lokalnymi, zarządzanie czasem, zarządzanie losowymi nasionami, zarządzanie zmiennymi sysctl, zarządzanie konsolą,. . .
Praca w toku:
Nad czym pracujemy:
- zarządzanie siecią
- systemd-networkd
- Lokalna pamięć podręczna DNS, odpowiadający mDNS, odpowiadający LLMNR, weryfikacja DNSSEC
- IPC w jądrze
- kdbus, sd-bus
- Synchronizacja czasu z NTP
- systemd-timesyncd
- Większa integracja z kontenerami
- Piaskownica usług
- Piaskownica aplikacji
- Format obrazu systemu operacyjnego
- Format obrazu kontenera
- Format obrazu aplikacji
- GPT z automatycznym wykrywaniem
- Systemy bezstanowe, systemy z możliwością aktualizacji, przywracanie ustawień fabrycznych
- / usr to system operacyjny
- / etc jest konfiguracją (opcjonalną)
- / var jest stanem (opcjonalnym)
- Inicjalizacja i aktualizacje węzłów atomowych
- Integracja z chmurą
- Zarządzanie usługami między węzłami
- Weryfikowalne obrazy systemu operacyjnego
- Aż do oprogramowania wewnętrznego
- Ładowanie rozruchu
Zakres tej odpowiedzi
Jak zauważył fpmurphy1 w komentarzach: „Należy zauważyć, że systemd rozszerzył zakres swojej pracy na przestrzeni lat daleko poza zwykłe uruchamianie systemu”.
Próbowałem zawrzeć tutaj większość istotnych informacji. W tym miejscu porównuję typowe funkcje Upstart i systemd, gdy są używane jako systemy init, jak podano w pytaniu, i wspominam tylko o cechach systemd, które wykraczają poza zakres systemu init, ponieważ nie można ich porównać do uruchamiania, ale ich obecność jest ważna zrozumieć różnicę między tymi dwoma projektami. Odpowiednią dokumentację należy sprawdzić, aby uzyskać więcej informacji.
Więcej informacji
Więcej informacji można znaleźć na stronie:
Dodatki
Zespół LinOxide stworzył zestaw plików Systemd vs. SysV Init Linux .