Włączanie „plików jednostkowych” w Systemd

Nadal mam problemy z systemd i wpadłem na coś. To nie jest problem, ale chciałbym dowiedzieć się więcej o tym, jak to jest. Nie mogłem znaleźć odniesienia do tego gdzie indziej.

Po pierwsze, rozumiem, że niestandardowe pliki jednostek dla usług powinny zostać wprowadzone /etc/systemd/system. Byłoby jednak miło dla zarządzania naszymi serwerami, gdyby pliki jednostek mogły być zlokalizowane gdzie indziej.

W dokumentacji widziałem, że możesz „linkować” pliki jednostek w następujący sposób:

systemctl link /path/to/servicename.service

Spowoduje to utworzenie linku do powyższego w /etc/systemd/system. Możesz teraz uruchomić / zatrzymać tę usługę. Z pozoru wydawało nam się to dobrym sposobem na zarządzanie naszymi usługami.

Jednak próba włączenia takiego „połączonego” pliku jednostki kończy się niepowodzeniem:

root@test1:/etc/systemd/system# systemctl link /root/myservice.service 
Created symlink from /etc/systemd/system/myservice.service to /root/myservice.service.

root@test1:/etc/systemd/system# systemctl status myservice.service 
 * myservice.service - My Test Service
     Loaded: loaded (/root/myservice.service; linked; vendor preset: enabled)

root@test1:/etc/systemd/system# systemctl enable myservice.service
Failed to execute operation: No such file or directory

Używając dokładnie tego samego pliku jednostkowego, ale skopiowanego do /etc/systemd/systemzamiast połączonego, otrzymujesz:

root@test1:/etc/systemd/system# cp -p /root/myservice.service .

root@test1:/etc/systemd/system# systemctl daemon-reload 

root@test1:/etc/systemd/system# systemctl status myservice.service 
 * myservice.service - My Test Service
     Loaded: loaded (/etc/systemd/system/myservice.service; disabled; vendor preset: enabled)

root@test1:/etc/systemd/system# systemctl enable myservice.service
Created symlink from /etc/systemd/system/multi-user.target.wants/myservice.service to /etc/systemd/system/myservice.service.

Z tego wynika, że ​​nie można włączyć wywoływania połączonych plików jednostek podczas uruchamiania systemu.

Jeśli tak jest, jaki jest sens funkcji „link”? Z dokumentów mówi:

link FILENAME

Połącz plik jednostki, który nie znajduje się w ścieżkach wyszukiwania pliku jednostki, ze ścieżką wyszukiwania pliku jednostki. Wymaga to bezwzględnej ścieżki do pliku jednostkowego. Efekt tego można cofnąć wyłączając. Efektem tego polecenia jest to, że plik jednostki jest dostępny do uruchomienia i innych poleceń, chociaż nie jest zainstalowany bezpośrednio w ścieżce wyszukiwania jednostek.

Strona podręcznika jest myląca.

systemctl link /root/myservice.service

systemctl enable /root/myservice.service

Pierwszy pozwala ci to zrobić systemctl start myservice. Drugi umożliwia myserviceautomatyczne uruchomienie (co, jak zauważył @Julien, automatycznie dodaje link).

Myślę, że ... Próbowałem to obejść cały dzień.

Podczas włączania usługi z innej ścieżki niż ścieżki domyślne należy użyć pełnej ścieżki. Włącz spowoduje również utworzenie linku:

systemctl enable /root/myservice.service

Po włączeniu możesz uruchomić / zatrzymać / status za pomocą nazwy usługi

systemctl start myservice

Kilka ostrzeżeń tutaj:

• nie można włączyć pliku usługi, który sam w sobie jest już linkiem
• upewnij się, że ścieżka znajduje się na tym samym zamontowanym dysku. Jeśli tak nie jest, systemd nie będzie mógł załadować plików jednostki serwisowej podczas rozruchu, ponieważ dysk nie zostanie jeszcze zamontowany i pliki nie zostaną znalezione. (patrz Pliki jednostki połączonej Systemd na zamontowanym dysku nie ładują się )
• z powodu błędu w systemied nie można włączyć instancji z pliku jednostki, który znajduje się w niestandardowej ścieżce (patrz https://github.com/systemd/systemd/issues/661 )