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.

Czynniki pierwsze systemd
Czynniki pierwsze systemd
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:

zadaniesysvinitsystemd
zadaniesysvinitsystemd
Uruchom usługęservice example startsystemctl start example
Zatrzymaj usługęservice example stopsystemctl stop example
Zrestartuj usługę (Stop - Start)service example restartsystemctl restart example
Przeładuj konfigurację usługiservice example reloadsystemctl reload example
Status usługiservice example statussystemctl status example
Zrestartuj usługę jeżeli działaservice example condrestartsystemctl condrestart example
Pozwól na start usługi przy uruchamianiu systemuchkconfig example onsystemctl enable example
Zabroń startu usługi podczas uruchamiania systemuchkconfig example offsystemctl disable example
Sprawdź czy usługa jest uruchamiana wraz ze startem systemuchkconfig examplesystemctl is-enabled example
Lista usług uruchamianych bądź nie wraz ze startem systemu chkconfig --listsystemctl list-unit-files --type=service
Informacje o konkretnej usłudzechkconfig example --list systemctl show example
Dodaj i skonfiguruj usługęchkconfig example --addsystemctl 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. 

10 komentarzy

  1. 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.

  2. “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.

  3. 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 🙂

  4. 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.

  5. 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.

  6. „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.

  7. Na szczęscie Chrome OS jest pozbawiony tej kobyły systemd i dlatego uruchamia się w kilka sekund.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Post comment

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.