Systemd ui opcje binarne

systemd to zestaw podstawowych elementów składowych systemu Linux. Zapewnia system i menedżera usług, który działa jako PID 1 i uruchamia resztę systemu. Systemd zapewnia agresywne funkcje równoległe, wykorzystuje aktywację gniazd i D-Bus do uruchamiania usług, oferuje uruchamianie demonów na żądanie, śledzi procesy za pomocą grup kontrolnych Linux. utrzymuje punkty montowania i automatyzacji oraz implementuje skomplikowaną logikę sterowania usługami opartą na zależności. systemd obsługuje skrypty startowe SysV i LSB i działa jako zamiennik dla sysvinit. Inne części obejmują demona rejestrowania, narzędzia do kontrolowania podstawowej konfiguracji systemu, takie jak nazwa hosta, data, ustawienia regionalne, utrzymywanie listy zalogowanych użytkowników oraz uruchamianie kontenerów i maszyn wirtualnych, kont systemowych, katalogów i ustawień środowiska wykonawczego oraz demonów do zarządzania prostą siecią konfiguracja, synchronizacja czasu sieciowego, przekazywanie logów i rozpoznawanie nazw. Uwaga: Aby uzyskać szczegółowe wyjaśnienie, dlaczego Arch został przeniesiony do systemd. zobacz ten post na forum. Podstawowe użycie systemctl Główne polecenie używane do introspekcji i kontroli systemd to systemctl. Niektóre z jego zastosowań sprawdzają stan systemu i zarządzają systemem i usługami. Zobacz man systemctl po więcej szczegółów. Wskazówka: Można użyć wszystkich następujących poleceń systemctl za pomocą przełącznika - H użytkownika, aby sterować instancją systemd na komputerze zdalnym. To będzie używać SSH do połączenia ze zdalną instancją systemd. systemadm jest oficjalnym graficznym interfejsem dla systemu systemctl i jest dostarczany przez pakiet systemd-ui. Użytkownicy plazmy mogą zainstalować systemd-kcm jako graficzną wersję fronted dla systemctl. Po zainstalowaniu moduł zostanie dodany w obszarze Administracja systemu. Analiza stanu systemu Pokaż status systemu za pomocą: Lista działających jednostek: Lista uszkodzonych jednostek: Dostępne pliki jednostek można zobaczyć w usrlibsystemdsystem i etcsystemdsystem (ten drugi ma pierwszeństwo). Lista zainstalowanych plików jednostek za pomocą: Używanie jednostek Jednostki mogą być na przykład usługami (.service), punktami montowania (.mount), urządzeniami (.device) lub gniazdami (.socket). Podczas korzystania z systemctl. zazwyczaj musisz podać pełną nazwę pliku jednostki, w tym jej sufiks, na przykład sshd. socket. Istnieje jednak kilka krótkich formularzy podczas określania jednostki w następujących komendach systemctl: Jeśli nie określisz sufiksu, system zacznie przyjmować. service. Na przykład netctl i netctl. service są równoważne. Punkty mocowania zostaną automatycznie przetłumaczone na odpowiednią jednostkę. Na przykład określenie domu to odpowiednik home. mount. Podobnie jak punkty montowania, urządzenia są automatycznie tłumaczone na odpowiednią jednostkę. device, dlatego określenie devsda2 jest równoważne dev-sda2.device. Więcej informacji na stronie man systemd. unit. Uwaga: Niektóre nazwy jednostek zawierają znak (np. Ciąg znaków. service): oznacza to, że są to instancje jednostki szablonu, której rzeczywista nazwa pliku nie zawiera części ciągu (np. Nazwa. serwis). ciąg jest nazywany identyfikatorem instancji. i jest podobny do argumentu, który jest przekazywany do jednostki szablonu po wywołaniu komendą systemctl: w pliku jednostki zastępuje specyfikator i. Aby być bardziej dokładnym, przed próbą utworzenia instancji nazwy name. suffix, systemd będzie szukał jednostki z dokładną nazwą pliku namestring. suffix, chociaż konwencja taka zdarza się rzadko, tzn. Większość plików jednostkowych zawierających znak jest przeznaczona być szablonami. Ponadto, jeśli jednostka szablonu zostanie wywołana bez identyfikatora instancji, po prostu zawiedzie, ponieważ nie można zastąpić specyfikatora i. Wskazówka: Większość poniższych poleceń działa również w przypadku określenia wielu jednostek, więcej informacji można znaleźć w man systemctl. Przełącznik --now może być używany w połączeniu z enable. wyłączyć. i maskuj, aby odpowiednio uruchomić, zatrzymać lub zamaskować natychmiast jednostkę, a nie po następnym rozruchu. Pakiet może oferować jednostki do różnych celów. Jeśli właśnie zainstalowałeś pakiet, pakiet pacp - Qql grep - Fe. service - e. socket może być użyty do sprawdzenia i znalezienia ich. Natychmiastowe uruchomienie urządzenia: Natychmiastowe zatrzymanie jednostki: Poproś jednostkę, aby ponownie załadowała swoją konfigurację: Pokaż status jednostki, w tym informację, czy jest ona uruchomiona, czy też nie: Sprawdź, czy urządzenie jest już włączone, czy nie: Włącz jednostkę, która ma być uruchomiona bootup. Wyłącz urządzenie, aby nie uruchamiać się podczas startu: zamaskuj jednostkę, aby uniemożliwić jej uruchomienie: Pokaż stronę podręcznika powiązaną z jednostką (musi to być obsługiwane przez plik jednostki): Załaduj ponownie systemd. skanowanie w poszukiwaniu nowych lub zmienionych jednostek. Polkit zarządzania energią jest niezbędny do zarządzania energią jako użytkownik nieuprzywilejowany. Jeśli użytkownik jest w sesji lokalnego użytkownika logu systemd i żadna inna sesja nie jest aktywna, następujące polecenia będą działały bez uprawnień root. Jeśli nie (na przykład, ponieważ inny użytkownik jest zalogowany do tty), systemd automatycznie zapyta cię o hasło roota. Zamknij system i zrestartuj system: Zamknij system i wyłącz system: Zawieś system: Przełącz system w stan hibernacji: Przełącz system w stan uśpienia hybrydowego (lub zawieś na obu): Zapisywanie plików jednostek Składnia systemu Pliki jednostek są inspirowane przez pliki konfiguracyjne XDG Desktop Entry. desktop, które z kolei inspirowane są plikami. ini Microsoft Windows. Pliki jednostek są ładowane z dwóch lokalizacji. Od najniższego do najwyższego pierwszeństwa są to: usrlibsystemdsystem. jednostki dostarczane przez zainstalowane pakiety etcsystemdsystem. Jednostki instalowane przez administratora systemu Uwaga: Ścieżki ładowania są zupełnie inne, gdy systemd działa w trybie użytkownika. Nazwy urządzeń systemd mogą zawierać wyłącznie znaki alfanumeryczne ASCII, podkreślenia i kropki. Wszystkie inne znaki muszą być zastąpione przez znaki C w stylu x2d. Zobacz man systemd. unit i man systemd-escape, aby uzyskać więcej informacji. Sprawdź przykładowe jednostki zainstalowane w twoich pakietach, a także przykładową sekcję przykładową man systemd. service. Wskazówka: Dodane komentarze mogą być również używane w plikach jednostek, ale tylko w nowych wierszach. Nie używaj komentarzy na końcu wiersza po parametrach systemd, bo urządzenie nie uruchomi się. Obsługa zależności Z systemd. zależności można rozwiązać, poprawnie projektując pliki jednostek. Najbardziej typowy przypadek polega na tym, że jednostka A wymaga, aby jednostka B działała przed uruchomieniem A. W takim przypadku dodaj Wymaga B i Po B do sekcji Jednostki A. Jeśli zależność jest opcjonalna, dodaj Wants B i After B. Zauważ, że Wants and Require nie implikuje After. co oznacza, że ​​jeśli nie zostanie określony parametr Po, obie jednostki zostaną uruchomione równolegle. Zależności są zwykle umieszczane na usługach, a nie na celach. Na przykład network. target jest pobierany przez dowolną usługę konfigurującą interfejsy sieciowe, dlatego zamawiasz niestandardową jednostkę, jeśli jest wystarczająca, ponieważ i tak uruchomiono network. target. Typy usług Podczas pisania niestandardowego pliku usługi należy wziąć pod uwagę kilka różnych typów uruchamiania. Jest to ustawione za pomocą parametru Type w sekcji Service: Typesimple (domyślnie): systemd uważa usługę, która ma zostać uruchomiona natychmiast. Proces nie może się rozwidlać. Nie używaj tego typu, jeśli inne usługi wymagają zamawiania w tej usłudze, chyba że jest ona aktywowana. Typeforking. systemd uważa usługę uruchomioną po rozwidleniach procesu i rodzic wyszedł. W przypadku klasycznych demonów używaj tego typu, chyba że wiesz, że nie jest to konieczne. Powinieneś również określić PIDFile, aby systemd mógł śledzić główny proces. Typeoneshot. jest to przydatne w przypadku skryptów wykonujących jedno zadanie, a następnie zakończonych. Możesz także ustawić RemainAfterExityes, aby systemd nadal uważał usługę za aktywną po zakończeniu procesu. Typenotify. identyczny z typem. ale z zastrzeżeniem, że demon wyśle ​​sygnał do systemd, gdy będzie gotowy. Referencyjną implementację tego powiadomienia dostarcza libsystemd-daemon. so. Typedbus. usługa jest uważana za gotową, gdy określone BusName pojawi się na magistrali systemowej DBuss. Typeidle. systemd opóźni wykonanie usługi binarnej, dopóki wszystkie zadania nie zostaną wysłane. Inne niż to zachowanie jest bardzo podobne do Typesimple. Zobacz stronę podręcznika systemd. service (5), aby uzyskać bardziej szczegółowe wyjaśnienie wartości typu. Edycja dostarczonych jednostek Aby uniknąć konfliktów z pacman, pliki jednostek dostarczane przez pakiety nie powinny być bezpośrednio edytowane. Istnieją dwa bezpieczne sposoby modyfikacji jednostki bez dotykania oryginalnego pliku: utwórz nowy plik jednostki, który zastępuje oryginalną jednostkę lub utwórz urywki wstawiane na wierzchu oryginalnej jednostki. W przypadku obu metod należy ponownie załadować urządzenie, aby zastosować zmiany. Można to zrobić poprzez edycję jednostki za pomocą edycji systemctl (która automatycznie ładuje urządzenie) lub przez ponowne załadowanie wszystkich jednostek za pomocą: Wskazówka: Możesz użyć systemd-delta, aby zobaczyć, które pliki jednostek zostały nadpisane lub rozszerzone i co dokładnie zostało zmienione . Użyj jednostki systemctl cat, aby wyświetlić zawartość pliku jednostki i wszystkich powiązanych fragmentów wklejonych. Podświetlanie składni dla plików jednostek systemowych w Vimie można włączyć przez zainstalowanie vim-systemd. Pliki jednostek zastępczych Aby zastąpić jednostkę urządzenia usrlibsystemdsystem. utwórz plik etcsystemdsystem unit i włącz ponownie jednostkę, aby zaktualizować dowiązania symboliczne: To otwiera jednostkę etcsystemdsystem w twoim edytorze (kopiowanie zainstalowanej wersji, jeśli jeszcze nie istnieje) i automatycznie ładuje ją po zakończeniu edycji. Uwaga: Pacman nie aktualizuje plików jednostek zastępczych podczas aktualizacji oryginałów, więc ta metoda może utrudnić konserwację systemu. Z tego powodu zalecane jest następne podejście. Pliki typu drop-in Aby utworzyć pliki wtyczek dla jednostki plików usrlibsystemdsystem. utwórz katalog etcsystemdsystem unit. d umieść tam pliki. conf, aby zastąpić lub dodać nowe opcje. systemd przeanalizuje pliki. conf i zastosuje je na wierzchu oryginalnej jednostki. Najprościej to zrobić: uruchom plik etcsystemdsystem. doverride. conf w edytorze tekstu (jeśli to konieczne) i automatycznie ponownie ładuje urządzenie po zakończeniu edycji. Przywróć wersję producenta Aby cofnąć wszelkie zmiany wprowadzone w jednostce utworzonej przy użyciu edytora systemctl: Na przykład, jeśli chcesz po prostu dodać dodatkową zależność do jednostki, możesz utworzyć następujący plik: Jako inny przykład, aby zastąpić ExecStart dyrektywę dla jednostki, która nie jest typu typu oneshot. utwórz następujący plik: Zauważ, jak należy wyczyścić ExecStart przed ponownym przypisaniem 1. To samo dotyczy każdego elementu, który można określić wiele razy, np. OnCalendar dla timerów. Jeszcze jeden przykład automatycznego restartowania usługi: Powód: niejasny opis, skopiowana zawartość (wyraźnie wspomina Fedorę). (Porozmawiaj w sekcji Talk: SystemdMake Cele bardziej wyraźnie) systemd używa celów, które służą podobnemu celowi jak poziomy pracy, ale działają trochę inaczej. Każdy cel jest nazwany zamiast ponumerowanych i ma służyć konkretnemu celowi z możliwością jednoczesnego działania wielu. Niektóre cele są realizowane przez dziedziczenie wszystkich usług innego celu i dodawanie do niego dodatkowych usług. Istnieją systemowe cele, które naśladują typowe poziomy pracy SystemVinit, dzięki czemu można nadal przełączać obiekty docelowe za pomocą znanego polecenia telinit RUNLEVEL. Uzyskaj aktualne cele Poniższe dane powinny być używane w systemie systemd zamiast w uruchomionym poziomie uruchamiania. Utwórz niestandardowy cel Poziomy pracy, które mają zdefiniowane znaczenie pod sysvinit (tj. 0, 1, 3, 5 i 6), mają odwzorowanie 1: 1 z określonym celem systemd. Niestety, nie ma dobrego sposobu, aby zrobić to samo dla zdefiniowanych przez użytkownika poziomów pracy, takich jak 2 i 4. Jeśli korzystasz z nich, sugeruje się utworzenie nowego nazwanego celu systemd jako systemu plików systemowych, który przyjmuje jeden z istniejących poziomów pracy jako bazę (możesz spojrzeć na przykład na usrlibsystemdsystemgraficzny. target), spraw, aby katalog etcsystemdsystem był Twoim celem. wants. a następnie dowiązanie symboliczne do dodatkowych usług z systemu usrlibsystem, które chcesz włączyć. Tabela celów Zmień bieżący cel W systemd cele są narażone przez jednostki docelowe. Możesz je zmienić w ten sposób: Zmieni to tylko bieżący cel i nie ma wpływu na następny rozruch. Jest to równoważne poleceniom takim jak telinit 3 lub telinit 5 w Sysvinit. Zmień domyślny cel, na który chcesz uruchomić Standardowy cel to default. target. domyślnie alias do pliku graficznego. target (który w przybliżeniu odpowiada starszemu poziomowi uruchamiania 5). Aby zmienić domyślny cel w czasie rozruchu, dołącz jeden z następujących parametrów jądra do bootloadera: systemd. unitmulti-user. target (który w przybliżeniu odpowiada starszemu poziomowi uruchamiania 3), systemd. unitrescue. target (który w przybliżeniu odpowiada stary poziom uruchamiania 1). Ewentualnie możesz zostawić bootloader sam i zmienić default. target. Można to zrobić za pomocą systemctl. Aby móc zastąpić wcześniej ustawiony plik default. target. użyj opcji force: Efekt tego polecenia jest wyprowadzany przez systemctl dowiązanie symboliczne do nowego domyślnego celu jest dokonywane w etcsystemdsystemdefault. target. Pliki tymczasowe systemd-tmpfiles tworzy, usuwa i usuwa zmienne i tymczasowe pliki i katalogi. Odczytuje pliki konfiguracyjne w plikach etctmpfiles. d i usrlibtmpfiles. d, aby dowiedzieć się, jakie akcje wykonać. Pliki konfiguracyjne w poprzednim katalogu mają pierwszeństwo przed plikami z tego ostatniego katalogu. Pliki konfiguracyjne są zwykle dostarczane razem z plikami serwisowymi i są nazywane w stylu pliku usrlibtmpfiles. d program. conf. Na przykład demon Samby oczekuje, że katalog runsamba istnieje i ma odpowiednie uprawnienia. Dlatego pakiet samba jest dostarczany z tą konfiguracją: Pliki konfiguracyjne mogą być również używane do zapisywania wartości do niektórych plików podczas rozruchu. Na przykład, jeśli użyłeś pliku etcrc. local, aby wyłączyć przebudzenie z urządzeń USB za pomocą echo USBE gt procacpiwakeup. zamiast tego możesz użyć następującego pliku tmpfile: Szczegółowe informacje znajdują się na stronach podręcznika systemd-tmpfiles (8) i tmpfiles. d (5). Uwaga: ta metoda może nie działać, aby ustawić opcje w systemie sys, ponieważ usługa systemd-tmpfiles-setup może działać przed załadowaniem odpowiednich modułów urządzeń. W takim przypadku możesz sprawdzić, czy moduł ma parametr dla opcji, którą chcesz ustawić za pomocą modułu modinfo i ustawić tę opcję na plik konfiguracyjny w etcmodprobe. d. W przeciwnym razie będziesz musiał napisać regułę udev, aby ustawić odpowiedni atrybut, gdy tylko pojawi się urządzenie. Timer jest jednostkowym plikiem konfiguracyjnym, którego nazwa kończy się na. timer i koduje informacje o czasomierzu kontrolowanym i nadzorowanym przez systemd. do aktywacji z timerem. Zobacz systemdTimers. Ponieważ systemd jest zamiennikiem dla init systemu V, jest odpowiedzialny za mounty określone w etcfstab. W rzeczywistości wykracza poza zwykłe możliwości fstab, implementując specjalne opcje montowania z prefiksem x-systemd. Zobacz FstabAutomount with systemd, aby zobaczyć przykład automatycznego montażu (montowania na żądanie) przy użyciu tych rozszerzeń. Zobacz 2 pełną dokumentację tych rozszerzeń. Systemd ma swój własny system logowania zwany dziennikiem, dlatego uruchomienie demona syslog nie jest już wymagane. Aby przeczytać log, użyj: W Arch Linux, katalog varlogjournal jest częścią pakietu systemd, a dziennik (gdy Storage jest ustawiony na auto w etcsystemdjournald. conf) napiszę do varlogjournal. Jeśli ty lub jakiś program usuniesz ten katalog, systemd nie utworzy go automatycznie i zamiast tego zapisze jego logi do systemystemdjournal w nietrwały sposób. Folder zostanie jednak odtworzony po ustawieniu Storagepersistent i uruchom systemctl restart systemd-journald (lub uruchom ponownie). Dziennik Systemd klasyfikuje wiadomości według priorytetu i łatwości. Klasyfikacja dzienników odpowiada klasycznemu protokołowi Syslog (RFC 5424). Poziom priorytetu Kod istotności syslog (w systemie nazwanym priorytetem) służy do oznaczania ważności komunikatu RFC 5424 sekcja 6.2.1. Tak więc, przydatne urządzenia do oglądania: 0,1,3,4,9,10,15. Filtrowanie dziennika wyjściowego umożliwia filtrowanie danych wyjściowych według określonych pól. Należy pamiętać, że jeśli istnieje wiele komunikatów do wyświetlenia lub filtrowania dużego zakresu czasu, dane wyjściowe tego polecenia mogą być opóźnione przez dłuższy czas. Wskazówka: Gdy dziennik jest przechowywany w formacie binarnym, zawartość zapisanych wiadomości nie jest modyfikowana. Oznacza to, że jest widoczny z ciągami. na przykład do odzyskiwania w środowisku, które nie ma zainstalowanego systemu. Przykładowa komenda: Pokaż wszystkie wiadomości z tego rozruchu: często jednak interesuje się wiadomościami nie z bieżącego, ale z poprzedniego rozruchu (np. W przypadku wystąpienia nieodwracalnej awarii systemu). Jest to możliwe poprzez opcjonalny parametr przesunięcia flagi - b: dziennik-b -0 pokazuje komunikaty z bieżącego rozruchu, dziennik-b -1 z poprzedniego rozruchu, dziennik-2 z drugiego poprzedniego i tak dalej. Zobacz man 1 journalctl dla pełnego opisu, semantyka jest znacznie potężniejsza. Pokaż wszystkie wiadomości od daty (i opcjonalny czas): Pokaż wszystkie wiadomości od 20 minut: Obserwuj nowe wiadomości: Pokaż wszystkie wiadomości według określonego pliku wykonywalnego: Pokaż wszystkie wiadomości według określonego procesu: Pokaż wszystkie wiadomości według określonej jednostki: Pokaż pierścień jądra Bufor: Pokaż tylko komunikaty o błędach, krytycznych i alarmowych. Można również użyć liczb, journalctl - p 3..1. Jeśli używane jest pojedyncze słowo kluczowe, journalctl - p 3 - uwzględniono również wszystkie wyższe poziomy priorytetu. Pokaż równoważnik auth. log przez filtrowanie w obiekcie syslog: Zobacz man 1 journalctl. człowiek 7 systemd. journal-fields. lub blogu Lennarts po szczegóły. Wskazówka: Domyślnie dziennik obcina linie dłuższe niż szerokość ekranu, ale w niektórych przypadkach może być lepiej włączyć zawijanie zamiast obcięcia. Można to kontrolować za pomocą zmiennej środowiskowej SYSTEMDLESS. która zawiera opcje przekazywane do less (domyślny pager) i domyślnie do FRSXMK (patrz man 1 less i man 1 journalctl, aby poznać szczegóły). Pomijając opcję S, dane wyjściowe będą zawijane zamiast obcinane. Na przykład uruchom journalctl w następujący sposób: Jeśli chcesz ustawić to zachowanie jako domyślne, wyeksportuj zmienną z limitu rozmiaru dziennika Jeśli dziennik jest trwały (nieulotny), jego limit rozmiaru jest ustawiony na wartość domyślną 10 rozmiar podstawowego systemu plików, ale ograniczony do 4 GiB. Na przykład w przypadku varlogjournal na partycji 20 GiB dane kroniki mogą zająć do 2 GiB. Na partycji o wielkości 50 GiB maksymalna wartość to 4 GiB. Maksymalny rozmiar dziennika trwałego można kontrolować, usuwając z niego komentarze i zmieniając następujące elementy: Możliwe jest również użycie mechanizmu nadpisywania konfiguracji urywki zamiast edycji globalnego pliku konfiguracyjnego. W takim przypadku nie zapomnij umieścić przesłonięć pod nagłówkiem Journal: zobacz man journald. conf, aby uzyskać więcej informacji. Ręczne czyszczenie plików dziennika Pliki dziennika można globalnie usunąć z varlogjournal za pomocą np. rm. lub może być przycięte zgodnie z różnymi kryteriami za pomocą journalctl. Przykłady: usuwaj zarchiwizowane pliki dziennika, dopóki miejsce na dysku, którego używają, nie spadnie poniżej 100 mln: spraw, aby wszystkie pliki dziennika zawierały dane starsze niż 2 tygodnie. Zobacz man journalctl, aby uzyskać więcej informacji. Journald w połączeniu z syslog Kompatybilność z klasyczną, nie-dziennikową świadomą implementacją syslog może być zapewniona poprzez umożliwienie systemd przesyłania dalej wszystkich wiadomości przez socket systemystemdjournalsyslog. Aby działał demon demona syslog z dziennikiem, musi on połączyć się z tym gniazdem zamiast z devlogiem (oficjalne ogłoszenie). Domyślnym plikiem journald. conf do przekazywania do gniazda jest ForwardToSyslogno, aby uniknąć narzutu systemowego, ponieważ rsyslog lub syslog-ng pobierają wiadomości z dziennika osobno. Przekaż dziennik do devtty12 Utwórz katalog wtyczek etcsystemdjournald. conf. d i utwórz w nim plik fw-tty12.conf: Określ inny dziennik do wyświetlenia Może zajść potrzeba sprawdzenia dzienników innego systemu, który jest martwy w systemie wodę, np. uruchamianie z systemu na żywo w celu odzyskania systemu produkcyjnego. W takim przypadku można zamontować dysk np. mnt. i podaj ścieżkę dziennika za pomocą - D --katalogu. tak jak: Porady i triki Włącz domyślnie zainstalowane jednostki. Powód: Jak działa z jednostkami, których dotyczy dana instancja (Dyskusje w systemie Talk: Systemd) Arch Linux jest dostarczany z usrlibsystemdsystem-preset99-default. preset zawierający wyłączone. Powoduje to, że systemctl domyślnie wyłącza wszystkie jednostki, tak że po zainstalowaniu nowego pakietu użytkownik musi ręcznie włączyć jednostkę. Jeśli to zachowanie nie jest pożądane, po prostu utwórz dowiązanie symboliczne z pliku etcsystemdsystem-preset99-default. preset do devnull, aby nadpisać plik konfiguracyjny. Spowoduje to włączenie domyślnego ustawienia systemctl dla wszystkich jednostek, które zostaną zainstalowane niezależnie od typu jednostki podanego w innym pliku w jednym katalogu konfiguracji s systemctl. Nie ma to wpływu na jednostki użytkownika. Zobacz stronę podręcznika systemd. preset, aby uzyskać więcej informacji. Uwaga: Włączenie wszystkich jednostek domyślnie może spowodować problemy z pakietami zawierającymi dwie lub więcej wzajemnie wykluczających się jednostek. Systemsetl preset jest przeznaczony do użytku przez dystrybucje i spiny lub administratorów systemu. W przypadku, gdy włączone są dwie jednostki będące w konflikcie, należy jawnie określić, który z nich ma być wyłączony w ustawionym pliku konfiguracyjnym, jak określono w podręczniku systemd. preset. Środowiska aplikacji w piaskownicy Plik jednostki może być tworzony jako piaskownica w celu izolowania aplikacji i ich procesów w zaostrzonym środowisku wirtualnym. systemd wykorzystuje przestrzenie nazw. biała-czarna lista możliwości. i grup kontrolnych do procesów kontenerowych poprzez rozbudowaną konfigurację środowiska wykonawczego. Ulepszanie istniejącego pliku systemd z piaskownicą aplikacji zazwyczaj wymaga testów prób i błędów połączonych z hojnym wykorzystaniem strace. rejestrowanie błędów i rejestrowanie błędów w dzienniku i dzienniku zdarzeń. Możesz najpierw przeszukać dokumentację upstream dla już wykonanych testów, aby oprzeć próby na. Kilka przykładów na to, jak można wdrożyć sandboxing z systemd: CapabilityBoundingSet definiuje zestaw dozwolonych możliwości na białej liście, ale może również służyć do czarnej listy konkretnych możliwości jednostki. Na przykład funkcja CAPSYSADM, która powinna być jednym z celów bezpiecznego obszaru izolowanego. CapabilityBoundingSet CAPSYSADM Bez ograniczeńSandboxing pokazuje pełnowymiarowy przykład funkcji systemd dla sandboxingu. Rozwiązywanie problemów Zbadanie błędów systemd Przykładowo zbadamy błąd związany z usługą load-moduły: 1. Znajdź usługi systemd, które nie mogą się uruchomić: 2. Ok, znaleźliśmy problem z usługą load-modules-load. Chcemy wiedzieć więcej: Jeśli identyfikatora procesu nie ma na liście, po prostu zrestartuj uszkodzoną usługę za pomocą systemctl restart systemd-modules-load 3. Teraz mamy identyfikator procesu (PID), aby dokładnie zbadać ten błąd. Wprowadź następujące polecenie z bieżącym identyfikatorem procesu (tutaj: 15630): 4. Widzimy, że niektóre konfiguracje modułu jądra mają nieprawidłowe ustawienia. Dlatego przyjrzyjmy się tym ustawieniom w etcmodules-load. d. 5. Komunikat o błędzie Nie można odnaleźć modułu blacklist usblp może być związany ze złym ustawieniem wewnątrz pliku blacklist. conf. Pozwala dezaktywować go, wstawiając końcowe przed każdą opcją znalezioną w kroku 3: 6. Teraz spróbuj uruchomić systemd-modules-load. Jeśli to się powiedzie, nie powinno to niczego sugerować. Jeśli zauważysz błąd, wróć do kroku 3 i użyj nowego PID do rozwiązania pozostałych błędów. Jeśli wszystko jest w porządku, możesz sprawdzić, czy usługa została pomyślnie uruchomiona: Często możesz rozwiązać takie problemy, jak pokazano powyżej. Więcej informacji na ten temat znajdziesz w Diagnozowanie problemów z ładowaniem. Diagnozowanie problemów z systemem rozruchowym ma kilka opcji diagnozowania problemów z procesem rozruchu. Zobacz debugowanie rozruchu i dokumentację debugowania systemd. Diagnozowanie problemów z określoną usługą Przyczyna: Może to nie spowodować wszystkich błędów, takich jak brakujące biblioteki. (Dyskusja w User talk: AlucrydPlex) Jeśli niektóre usługi systemowe działają niepoprawnie i chcesz uzyskać więcej informacji o tym, co się dzieje, ustaw zmienną środowiskową SYSTEMDLOGLEVEL na debugowanie. Na przykład, aby uruchomić demona systemud-networkd w trybie debugowania: Lub, równoważnie, zmodyfikuj plik usługi tymczasowo w celu zebrania wystarczającej ilości danych wyjściowych. Na przykład: jeśli informacje debugowania są wymagane długoterminowo, dodaj zmienną w zwykły sposób. Shutdownreboot trwa strasznie długo Jeśli proces zamykania zajmuje bardzo dużo czasu (lub wydaje się, że zamarza), najprawdopodobniej przyczyną jest nieoczekiwana usługa. systemd czeka trochę czasu na zakończenie każdej usługi, zanim spróbuje ją zabić. Aby dowiedzieć się, czy jesteś dotknięty, zobacz ten artykuł. Krótkotrwałe procesy nie wydają się logować żadnego wyjścia Jeśli dziennik-lpu nie pokazuje żadnego wyniku dla krótkiej usługi, spójrz na PID. Na przykład, jeśli systemd-modules-load. service ulegnie awarii, a systemctl status systemd-modules-load pokazuje, że działa on jako PID 123, wtedy możesz zobaczyć dane wyjściowe w dzienniku dla tego PID, tj. Journalctl - b PID61123. Pola metadanych dziennika, takie jak SYSTEMDUNIT i COMM, są gromadzone asynchronicznie i polegają na katalogu proc dla istniejącego procesu. Naprawienie tego wymaga naprawy jądra w celu dostarczenia tych danych poprzez połączenie z gniazdem, podobne do SCMCREDENTIALS. Czas ładowania rośnie w miarę upływu czasu Po użyciu analizy systemd wielu użytkowników zauważyło, że ich czas rozruchu znacznie wzrósł w porównaniu z tym, co kiedyś było. Po użyciu systemd-analysis winę NetworkManager raportuje się jako rozpoczęcie wyjątkowo dużej ilości czasu. Problem niektórych użytkowników wynika z tego, że varlogjournal staje się zbyt duży. Może to mieć inny wpływ na wydajność, na przykład dla statusu systemctl lub journalctl. Rozwiązaniem jest usunięcie każdego pliku w folderze (najlepiej wykonanie jego kopii zapasowej, przynajmniej tymczasowo), a następnie ustawienie limitu rozmiaru pliku kroniki zgodnie z limitem rozmiaru dziennika. systemd-tmpfiles-setup. service nie uruchamia się przy starcie Począwszy od systemd 219, usrlibtmpfiles. dsystemd. conf określa atrybuty ACL dla katalogów pod varlogjournal i dlatego wymaga włączenia obsługi ACL dla systemu plików, na którym znajduje się dziennik. Zobacz listy kontroli dostępu Wybranie listy ACL, aby uzyskać instrukcje włączania listy ACL w systemie plików, w którym znajduje się plik varlogjournal. systemctl enable fail dla dowiązań symbolicznych w systemie plików etcsystem Jeśli system plików fs. systems jest dowiązaniem symbolicznym, a systemctl enable foo. service jest uruchomione, to nie powiedzie się z tym błędem: To jest wybór systemu. Aby obejść ten problem, włączanie przez bezwzględną ścieżkę działa: usługi zależne nie są uruchamiane podczas ręcznego uruchamiania usługi Jednym (nie) znanym przykładem jest libvirtd. service, która wymaga prawidłowego działania virtlogd. socket. Zależności w usrlibsystemdsystemlibvirtd. service są zdefiniowane jako To definiuje tylko niezbędne niezależne gniazda, które mają być włączone (np. Jako autostart), ale nie uruchamia ich za każdym razem, gdy usługa WYŁĄCZONA (niezautamartowania) jest uruchamiana ręcznie, np. uruchamiając systemctl start libvirtd W ten sposób poprawny sposób () ręcznego uruchomienia usługi z zależnymi podserwisami jeden raz (zamiast na każdym uruchomieniu systemu) Prawdopodobnie jest to wersja systemd wydrukowana podczas rozruchu nie jest taka sama jak zainstalowana wersja pakietu Musisz zregenerować initramfs i wersje powinny się zgadzać. Wskazówka: Hak do pacmana może być użyty do automatycznej regeneracji initramfs za każdym razem, gdy uaktualniany jest systemd. Zobacz ten wątek na forum, a PacmanHooks. systemd to system i menedżer usług dla systemu Linux, kompatybilny ze skryptami inicjującymi SysV i LSB. systemd zapewnia agresywne funkcje równoległe, wykorzystuje aktywację gniazd i D-Bus do uruchamiania usług, oferuje uruchamianie demonów na żądanie, śledzi procesy za pomocą cgroups systemu Linux, obsługuje migawkę i przywracanie stanu systemu, utrzymuje punkty montowania i automowania oraz implementuje rozbudowana logika sterowania usługami oparta na zależności transakcyjnej. Może pracować jako zamiennik dla sysvinit. Aby uzyskać więcej informacji, obejrzyj wideo na youtubewatchvTyMLi8QF6sw Dla administratorów systemu Administratorzy systemu mogą odwiedzić tę stronę. zrozumieć, jak używać natywnych wywołań systemctl, które zastępują ich stary przepływ pracy w SysVinit. Zauważ, że polecenia service i chkconfig będą działały zgodnie z oczekiwaniami w świecie systemowym. Dlaczego systemd systemd documentd ma bardzo obszerną dokumentację. Zobacz Boot Kernel Command Line On boot systemd (domyślnie) aktywuje domyślną jednostkę docelową. target, którego zadaniem jest aktywowanie usług i innych jednostek przez przeciągnięcie ich przez zależności. Aby przesłonić jednostkę do aktywacji, systemd analizuje własne argumenty wiersza komend jądra za pomocą opcji wiersza poleceń systemd. unit. Może to być użyte do tymczasowego uruchomienia w innej jednostce rozruchowej. Klasyczne poziomy uruchamiania są zastępowane następująco: systemd. unitrescue. target jest specjalną jednostką docelową do konfigurowania systemu podstawowego i powłoki ratunkowej (podobnej do uruchomienia poziomu 1) systemd. unitemergency. target. jest bardzo podobny do przekazywania initbinsh, ale z opcją uruchomienia pełnego systemu z tego miejsca systemd. unitmulti-user. target do ustawienia nie-graficznego systemu wielodostępowego systemd. unitgraphical. target do ustawienia graficznego ekranu logowania. Aby uzyskać szczegółowe informacje na temat tych specjalnych systemowych jednostek startowych, zobacz stronę systemd. special man. to skrypty Jakie jest narzędzie do zarządzania usługami z systemd systemctl jest podstawowym narzędziem do użycia. Łączy funkcje zarówno usługi, jak i chkconfig w jedno narzędzie, które można wykorzystać na przykład do włączania usług na stałe lub tylko dla bieżącej sesji. wymień wszystkie uruchomione usługi itp: Więcej informacji znajdziesz w man systemctl. systemd-cgls wymienia działający proces w formacie drzewa. Może rekursywnie wyświetlać zawartość dowolnej grupy kontrolnej. Więcej informacji znajduje się w man systemd-cgls. Jak uruchomić usługi startstop lub enableisable Natychmiast aktywuje usługę: Natychmiast dezaktywuje usługę: Restartuje usługę: Pokazuje stan usługi, w tym czy jest uruchomiony, czy nie: Włącza usługę przy starcie: Wyłącza usługę, aby się nie uruchamiać podczas bootup: Zapobieganie uruchamianiu usługi dynamicznie lub nawet ręcznie, chyba że jest niezamaskowane: sprawdź, czy usługa jest już włączona, czy nie: więcej informacji na ten temat można znaleźć w man systemctl. Jak zmienić cel (runlevel) systemd ma koncepcję celów, która jest bardziej elastycznym zamiennikiem poziomów pracy w sysvinit. Poziom uruchamiania 3 jest emulowany przez multi-user. target. Poziom uruchamiania 5 jest emulowany przez graphical. target. runlevel3.target jest dowiązaniem symbolicznym do multi-user. target a runlevel5.target jest dowiązaniem symbolicznym do graphical. target. Możesz przełączyć się na poziom pracy 3, uruchamiając Możesz przełączyć się na poziom pracy 5, uruchamiając Jak zmienić domyślny cel graficzny. target jest domyślny. Możesz potrzebować multi-user. target dla odpowiednika nie graficznego (runlevel 3) z sysv init. Dostęp do pełnej listy celów można uzyskać za pośrednictwem systemctl list-units --typetarget systemd nie używa pliku etcinittab. Skąd mam wiedzieć, jaki jest obecny cel? Jak wyłączyć maszynę? Inne możliwości to: halt - p. init 0. shutdown - P teraz Zauważ, że halt działał tak samo jak poweroff w poprzednich wydaniach Fedory, ale systemd rozróżnia te dwa, więc zatrzymanie bez parametrów powoduje teraz dokładnie to, co mówi - zatrzymuje jedynie system bez wyłączania go. Does service command work with systemd Yes. It has been modified to call systemctl automatically when dealing with systemd service files. So either of the following commands does the same thing Does chkconfig command work with systemd Yes, for turning onoff services, compatibility has been provided both ways. chkconfig has been modified to call systemctl when dealing with systemd service files. Also systemctl automatically calls chkconfig when dealing with a traditional sysv init file. So either of the following commands does the same thing chkconfig --list doesnt list systemd services, only Sys V services. The output of chkconfig takes note of this, along with supplying additional information. Does system-config-services work with systemd How do I change the number of gettys running by default The simplest way is to edit etcsystemdlogind. conf (man page ): This setting will take effect after reboot. Alternatively, getty. services which open the login prompt can be enabled and started individually. To add another getty: To remove a getty: systemd does not use etcinittab file. How do I set automatic login on a virtual console terminal First create a new service similar to getty. service: then edit ExecStart, Restart and Alias values, like this: and finally reload daemon and start the service: Note that if you exit tty8 session, you wont be able to use it until next reboot or manual start by systemctl, except if you leave Restart as always, but I highly recommend to avoid this according to security reasons. How do I customize a unit file add a custom unit file The best way to customize unit files is to add etcsystemdsystemfoobar. service. d.conf where foobar. service is the name of the service you want to customize. If a directory doesnt already exist, create one and drop a conf file with the settings you want to override. For example, Refer to man systemd. unit page for more details. Dont forget to reload systemd daemon using systemctl daemon-reload and systemctl restart foobar after editing a unit file where foobar is the name of the unit. Also note that you can systemd-delta to list the unit files which have been customized and also the precise differences Special care must be taken when overriding options which can be set muliple times ( ExecStart. ExecStartPre. ExecStartPost are a common example). Assigning some value to the option appends to the existing list, while assiging the empty value resets the list. For example, lets say we have a service file like this: When started, this service will print The same rules apply to snippets in. d directories. This means that snippets which override ExecStart and similar settings, often should start with the empty assignment ExecStart. followed by the new setting. How do I debug systemd issues systemd comes with extensive documentation including several man pages. Referencessystemd - An alternative boot manager systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. See the systemd home page for further information. Warning Experimental code systemd is under active development in Ubuntu although the rough plan would be to default to systemd during development of 15.04. If you want to help its best to be running 15.04. (14.10 might be doable as well..) Installing systemd in Ubuntu may limit the amount of help and support available to you. If you have a commercial support agreement then installing systemd would almost certainly invalidate it. Even if you rely on forums etc, you will probably have to reproduce problems on a standard Ubuntu build before anyone can help you much. If you want to quickly try out systemd, it may be a good idea to create a sandpit system for the purpose (e. g. a virtual machine that you can easily re-install or delete afterwards). If you are installing systemd on a system containing data that you care about, please take a full backup first, and make a plan for restoring from backup in the event that the system ends up unbootable. Personal Package Archive location systemd and related packages are available on this PPA To use the PPA, first add it to your software sources list as follows. Installing systemd systemd can be installed from the PPA as follows. This results in systemd being installed alongside upstart. Boot loader configuration After installation, the machine will still boot under upstart by default. To boot under systemd, the following argument must be specified on the kernel command line: Note that the systemd binary resides now in libsystemd and binsystemd is just a symlink to it. To boot under systemd by default, edit etcdefaultgrub and change the following line: After modifying any grub related configuration files like etcdefaultgrub the following command is needed to bring the changes into effect. systemd prints the following warning on boot: It is advisable to do as suggested and replace etcmtab . It is not only mount that will behave incorrectly otherwise, but also df and probably most other commands that look at the list of mounted filesystems. This change can be made as follows. Using systemd To boot under systemd, select the boot menu entry that you created for the purpose. If you didnt bother to create one, just select the entry for your patched kernel, edit the kernel command line directly in grub and add initlibsystemdsystemd . If a normal boot under systemd is not successful then it is worth trying with the following parameters: systemd. unit specifies the target state that the system should boot to (similar to specifying a run level under sysvinit). emergency. service launches an emergency bash shell on the console without attempting to start any other services. Controlling systemd once booted The main command used to control systemd is systemctl . Some of its subcommands are as follows. systemctl list-units - List all units (where unit is the term for a jobservice) systemctl start NAME. - Start (activate) one or more units systemctl stop NAME. - Stop (deactivate) one or more units systemctl enable NAME. - Enable one or more unit files systemctl disable NAME. - Disable one or more unit files systemctl reboot - Shut down and reboot the system For the complete list, see systemctl(1). systemadm is the GUI equivalent to systemctl . if you like that sort of thing. Remote filesystem mounts If you have NFS mounts listed in etcfstab then systemd will attempt to mount them but will typically do so too early, before networking has been configured. To get the timing correct we need to tell systemd explicitly that the mount depends on networking and on rpc. statd . To do this, create a file under libsystemdsystem named ltmount-unit-namegt. mount with contents as follows. mount-unit-name is the full path to the mountpoint in an escaped format. For example, a mount unit for usrlocal must be named usr-local. mount . mountpoint is the local mountpoint server : share specify the remote filesystem in the same manner as for etcfstab See systemd. unit(5) and systemd. mount(5) for further details. A similar approach will probably be required for other remote filesystem types such as nfs4 and cifs Useful snippets To see which other units a service depends on: systemd quickstart for upstart users Implementation issues Packaging of units A unit properly belongs in the package of the daemon that it starts. systemd units are already included in some upstream packages and some Debian Experimental packages. They will probably appear in Ubuntu packages in due course, unless Ubuntu maintainers deliberately remove them. The systemd-extra-units package is intended only to make systemd usable in the short term by shipping some important units that dont yet exist in other Ubuntu packages. It should be scaled back as and when units start to appear in their proper places, and should eventually be dropped. Dependencies on things not yet available in Ubuntu Upstream systemd depends on recent upstream changes to several other packages that are not yet available in Ubuntu. These have been worked around by reverting the relevant changes in systemd or disabling the relevant feature. In brief these are: systemd 15 wants libnotify gt 0.7 and vala 0.11 Relevant changes have been reverted in order to build with libnotify 0.5.0 and vala 0.9. systemd wants sbinagetty but DebianUbuntu renames it to sbingetty sbinagetty will be added as a link in Debian wheezy (Debian bug 603786 ). systemd invokes agetty - s where the option - s was added by recent upstream commits in util-linux . Units getty. service and serial-getty. service have been patched to remove this option. systemd-fsck invokes fsck - l where the option - l was added by recent upstream commits in util-linux systemd-fsck has been patched to remove this option. Networking NetworkManager. service just starts NetworkManager and does not wait for it to bring up a network interface. This seems appropriate, but network. target should not become active until a network connection is up. An extra unit, wait-for-network. service . has been created to delay network. target . The appropriate way to wait for a network connection with NetworkManager appears to be nm-online . but this binary is not shipped in the Debian or Ubuntu packages for some reason. For systemd-extra-units 0.2 a simple shell loop has been used. This is effective, but hardly in the spirit of systemd. TODO: Ask whether nm-online could be shipped in the network-manager package, or re-implement something similar if not. NOTE: The network-manager package from Debian experimental does ship nm-online and will be uploaded to wheezy as soon as squeeze is released. Remote filesystem mounts systemd reads etcfstab and automatically creates a mount unit for each entry. The automatically generated dependencies for these units are insufficient in the case of remote filesystems. The correct dependencies can be specified explicitly in a mount unit configuration file (see above) but ideally this should be handled automatically. Proposal: When parsing an etcfstab entry, systemd should look for a unit template named after the filesystem type (e. g. nfs. mount for an NFS mount). If a template is found it should be used, with appropriate substitutions. Otherwise systemd should fall back to creating the mount unit with default settings as per the current behaviour. TODO: Write a patch for this and propose it upstream. The upstart job for portmap saves state using pmapdump and restores it using pmapset . The sysvinit script in Debian does the same thing. These actions appear redundant because portmap itself saves state to varrunportmapmapping after each change. My guess is that this is all based on instructions in the upstream source README, which may be out of date or just misleading. TODO: Confirm whether pmapdump pmapset really serve some purpose and include them in the systemd unit if so. etccron. danacron invokes anacron via the upstart job, which wont work while booted under systemd. A change to the anacron package would be needed to address this. etcdefault Existing sysvinit style scripts read configuration in the form of variable assignments from a file under etcdefault . A policy decision is needed on whether systemd units will do the same. Advantages: Separates configuration from code, simplifies package upgrade (i. e. same reasoning that applies to the existing sysvinit scripts). Disadvantages: Extra complexity. Some may argue that systemd units are simple enough to be treated entirely as configuration files. etcdefault files can be read using the EnvironmentFile parameter in a systemd service unit. However, this is not fully compatible with the shell. In particular the quoting rules differ. It is not possible to write an environment variable assignment containing whitespace or literal quotes in a way that both a legacy init script and systemd will understand. TODO: Decide whether systemd will use etcdefault files. Needs discussion with Debian maintainers. There would be little benefit in Ubuntu going its own way on this. TODO: Finish off patch for shell compatible quoting support and submit upstream. Other TODO Items Unit(s) for static network configuration without NetworkManager . Units for remaining native Upstart jobs in a default Ubuntu install that dont currently have systemd equivalents: apport cups log dmesg after boot failsafe X session irqbalance bring up virtual network devices Desktop integration for systemadm Plymouth integration Workarounds Failures on software-upgrades The post-installation script of packages uses sbinstart and sbinstop to start and stop (running) services in an upstart environment. Both binaries are symlinks to sbininitctl shipped with upstart package. Unfortunately, software-upgrades break when switching to systemd as an alternative init-system on Ubuntu systems, more precisely the software-management tool dpkg breaks. NOTE: Below workarounds were tested on Ubuntuprecise with a very early systemd v43 (so be careful). Bug 1008837 cups fails to installupgrade with systemd A little demo Workaround: Using an initctl replacement On IRC I discussed with Michael Biebl and others on the topic and Michael had concerns using bintrue as a symlink to sbinstart and sbinstop . In the end, the idea of an initctl replacement was born. Rename the original sbininitctl binary: Edit a new sbininitctl replacement file (Thanks mbiebl and grawity): Make the new script executable: Create and list a divert for the original initctl (this prevents e. g. its removal on upgrades): Remove the new divert in case you want to restore original behaviour: Software-upgrades touching startstop of daemons should now work fine within an upstart or systemd environment. systemd ( pitti 2018-01-22 09:56:01)