Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.
Data publikacji: 28-08-2015 | Autor: | Grzegorz Kuczyński |
Systemd posługuje się unitami w ramach wielu różnych aspektów zarządzania systemem, nie tylko w stosunku do usług. Samych typów unitów jest aż dwanaście i wiele z nich obsługuje się w charakterystyczny dla nich sposób. W poprzedniej części opisaliśmy idee aktywacji usług poprzez gniazda (socket) – tzw. socket-base activation, na wzór demona inetd. Jednak systemd oferuje znacznie więcej tego typu mechanizmów – np. aktywację poprzez system plików i urządzenia. Potrafi on uruchomić zadaną usługę wtedy, gdy podłączymy do systemu jakieś urządzenie, np. po podłączeniu drukarki wystartuje usługa CUPS. Innym przykładem jest sytuacja, gdy podczas uruchamiania systemu znajdują się w kolejce jeszcze zadania do wydrukowania. Wtedy możemy wykorzystać mechanizm path-base activation w celu uruchomienia usługi CUPS. Istnieje również możliwość aktywacji za pomocą unitu typu .timer, co odpowiada komendzie at, lecz odbywa się to w bardziej zorganizowany i scentralizowany sposób. Tak więc systemd oferuje administratorowi systemu coś więcej niż tylko ustalanie, w jakim celu mają być włączane usługi i jaka ma być kolejność ich uruchamiania. Systemd daje ogromne możliwości konfiguracji procesów, które uruchamia.
Pliki unit składają się z trzech głównych sekcji, które definiują różne aspekty zachowania się unitów:
Najprostsza forma pliku unit dla przykładowej usługi (np. plik srv.service) wygląda następująco:
[Unit]
Description=srv
[Service]
ExecStart=/usr/sbin/srv-daemon
[Install]
WantedBy=multi-user.target
Artykuł pochodzi z miesięcznika: IT Professional
Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.
Transmisje online zapewnia: StreamOnline