Terminal pogryzł człowieka: systemd
Choć starych drzew się nie przesadza i wbrew zasadzie „po co zmieniać sysvinit skoro działa”, otwarty świat poszedł na współpracę z demonizowanym systemd. Zwykłym użytkownikom nie pozostał nic innego, jak dostosować się do zmian w krajobrazie i odnaleźć się w zmodernizowanej nomenklaturze zawiadywania usługami linuksowymi i nie tylko. A jest to proces nieuchronny, gdyż 98% nowych dystrybucji korzysta już ze wspomnianego systemd. Nawet nadchodzące Ubuntu 16.04 LTS.
Systemd jest stosunkowo nowym systemem (Fedora 15 jako pierwsza dystrybucja wymieniła upstart na systemd) inicjalizacji i obsługi komponentów systemowych. Wymyślony jako następca sysvinit jest jednak z nim kompatybilny (i z jego skryptami), a sam w miejsce dawnych skryptów bashowych oferuje pliki .service opisujące warunki uruchamiania usług. Najistotniejsze cechy całości to:
- możliwość równoległego uruchamiania usług,
- uruchamianie zadań za pomocą socketów D-Bus,
- uruchamianie usług na żądanie,
- śledzenie działania procesów przy pomocy grup kontrolnych (cgroups),
- wsparcie dla zachowywania i przywracania stanu usług w systemie,
- utrzymanie punktów montowania i automatycznego montowania w systemie,
- oparta na zależnościach logika kontroli usług,
- działa jako zamiennik SysVinit.
Do kontrolowania zadań służy narzędzie systemctl i to na nim skupimy się dzisiaj. Jak bowiem na język systemd przełożyć większość poleceń którymi posługiwaliśmy się do tej pory, aby obsłużyć usługi i komponenty systemowe? Nieodzowna można stać się skrócona ściąga:
zadanie | sysvinit | systemd |
---|---|---|
zadanie | sysvinit | systemd |
Uruchom usługę | service example start | systemctl start example |
Zatrzymaj usługę | service example stop | systemctl stop example |
Zrestartuj usługę (Stop - Start) | service example restart | systemctl restart example |
Przeładuj konfigurację usługi | service example reload | systemctl reload example |
Status usługi | service example status | systemctl status example |
Zrestartuj usługę jeżeli działa | service example condrestart | systemctl condrestart example |
Pozwól na start usługi przy uruchamianiu systemu | chkconfig example on | systemctl enable example |
Zabroń startu usługi podczas uruchamiania systemu | chkconfig example off | systemctl disable example |
Sprawdź czy usługa jest uruchamiana wraz ze startem systemu | chkconfig example | systemctl is-enabled example |
Lista usług uruchamianych bądź nie wraz ze startem systemu | chkconfig --list | systemctl list-unit-files --type=service |
Informacje o konkretnej usłudze | chkconfig example --list | systemctl show example |
Dodaj i skonfiguruj usługę | chkconfig example --add | systemctl edit --full example |
To większość podstawowych operacji które zwykle przeprowadzamy manipulując usługami systemowymi. Nie wyczerpuje to możliwości systemd / systemctl i jeżeli ktoś chce doskonalić swe umiejętności dalej, powinien zapoznać się z pełniejszym rozpisaniem opcji systemd.
To ten init “NSA approved”…
Systemd to monolit jak Xorg trudno to ogarnąć od środka. Też mam dziwne wrażenie że to taki twór jak Selinux i z NSA coś wspólnego może mieć, przyszłe podwaliny do trudniejszego wykrywania bugów(tylnych furtek służb) w systemach Linux. Tak szukam łatwej dystrybucji bez systemd, a jak nie znajdę nic, może skuszę się na Slackware. Ponoć ta wersja Slackware Live CD od BobaAliena ma posiadać niebawem graficzny instalator.
Niby nikt tego nie lubi, ale jako deweloper powiem tylko tyle: Unifikacja = <3.
“My jesteśmy systemd. Zostaniesz zasymilowany. Opór jest daremny.” 😉
Używam od 2013r., kiedy instalacja w Debianie jessie (wówczas testowej) wymagała trochę zachodu.
Zdziwiłem się mocno, widząc start systemu w kilkanaście sekund w porównaniu z sysvinit i upstart, a zamknięcie – niemal w okamgnieniu. Po zainstalowaniu dysku SSD, start od wyjścia z GRUBa do załadowania się lightdm trwa całe 3.5s 🙂
O ile bardzo podoba mi się złączenie zarządzania usługami, punktami montowania, targetami czy socketami w jedną całość, o tyle fakt, że systemd zawiera za dużo luźno związanej funkcjonalności: zarządzania dziennikami, analizy startu systemu, pytania o hasła, zarządzania połączeniami sieciowymi czy energią, naraża go na bugi.
Tak, i te jego serwisy zamiast pisania skryptów startowych… damn, jakie to jest proste w pisaniu!
Bez systemd – z tych łatwiejszych, przyjemniejszych masz np. Manjaro Linux (są wersje z OpenRC). Całkiem przyjemne distro oparte na Archu. No i zawsze pozostaje Gentoo 🙂
Nie, chociaż jak czytam to faktycznie mogło to tak brzmieć. Pisałem kiedyś skrypty startowe i jak po przejściu na systemd zorientowałem się, jakie teraz proste jest stworzenie nowej usługi, to mnie wbiło w fotel.
Jeśli zawsze startujesz z DM, to lepiej:
# systemctl enable lightdm
i jeśli chcesz go wystartować w tej sesji: # systemctl start lightdm
Pierwsze polecenie sprawi, że systemd podniesie lightdm przy każdym starcie systemu automatycznie.
„po co zmieniać sysvinit skoro działa”
Problem w tym, że sysvinit tak naprawdę nigdy nie działał prawidłowo i dlatego już dawno powstał upstart, który jednak rozwiązał jedynie cześć problemów. Upstart przez swoją licencję nie był zbyt elastyczny i stety lub niestety powstał systemd, który (przynajmniej teoretycznie) problemy rozwiązał.
Nawet konserwatywny Debian postanowił pozbyć się w końcu ułomnego sysvinita (z domyślnego systemu).
Można mieć wile zastrzeżeń merytorycznych lub ideologicznych do systemd, ale należy pamiętać o tym, że sysvinit to zwyczajnie syf, kiła i mogiła. O ile ułomności sysvinita były akceptowalne w latach ’90, to aktualnie są nie do przyjęcia w nowoczesnych systemach operacyjnych i nikt poza garstką anonimowych krzykaczy za sysvinitem nie tęskni.
Na szczęscie Chrome OS jest pozbawiony tej kobyły systemd i dlatego uruchamia się w kilka sekund.