I odczytać , że istnieją dwa foldery do plików jednostkowych (nie w trybie użytkownika).

/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator

Z tym rozumowaniem sprzeczna jest następująca odpowiedź: https://unix.stackexchange.com/a/47715/33386 . Czy ktoś może uzupełnić brakujące informacje, aby zrozumieć, co się dzieje? ( AKTUALIZACJA: Odpowiedź została zaktualizowana i moje rozumienie nie jest już z nią sprzeczne. )

Wydaje się również, że skrypty są zorganizowane w podfolderach w /etc/systemd/system/folderze:

getty.target.wants
multi-user.target.wants

W innej lokalizacji przeczytałem, że istnieją inne lokalizacje. Wygląda na to, że dotyczą one usług specyficznych dla użytkownika.

/usr/lib/systemd/user/ where services provided by installed packages go.
/etc/systemd/user/ where system-wide user services are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own services.

Aktualizacja 31.08.2015:

Ze względu na innych, oto link do powiązanego pytania, które niedawno zadałem: Gdzie umieścić skrypty wykonywane przez jednostki systemowe?

Najlepsze miejsce na umieszczenie plików jednostki systemowej : po /etc/systemd/system prostu dodaj cel w sekcji [Instaluj], przeczytaj „Skąd to wie”? dla szczegółów. AKTUALIZACJA : /usr/local/lib/systemd/systemto kolejna opcja, przeczytaj „Szary obszar”, aby poznać szczegóły. ”

Najlepsze miejsce na umieszczenie plików jednostek użytkownika : /etc/systemd/user lub $HOME/.config/systemd/user zależy to od uprawnień i sytuacji.

Prawda jest taka, że ​​jednostki systemowe (lub jak to nazywa zdanie wprowadzające, „konfiguracje jednostek”) mogą iść wszędzie - pod warunkiem, że chcesz tworzyć ręczne dowiązania symboliczne i masz świadomość zastrzeżeń. Ułatwia życie, umieszczając urządzenie tam, gdzie systemctl daemon-reloadmożna je znaleźć, z kilku dobrych powodów:

• Użycie standardowej lokalizacji oznacza, że ​​systematyczne generatory je odnajdą i ułatwią włączenie przy rozruchu systemctl enable. Wynika to z faktu, że twoja jednostka zostanie automatycznie dodana do drzewa zależności jednostek (pamięć podręczna jednostek).
• Nie musisz myśleć o uprawnieniach, ponieważ tylko uprawnieni użytkownicy mogą pisać w wyznaczonych obszarach.

Skąd to wie?

A skąd dokładnie systemctl enablewie, gdzie utworzyć dowiązanie symboliczne? Zakodujesz go na stałe w samej jednostce pod [install]sekcją. Zwykle jest taka linia

[Install]
WantedBy = multi-user.target

który odpowiada predefiniowanemu miejscu w systemie plików. W ten sposób systemctlwie, że ta jednostka jest zależna od grupy plików jednostek o nazwie multi-user.target(„cel” jest terminem używanym do oznaczania grup zależności jednostek. Możesz wymienić wszystkie grupy za pomocą systemctl list-units --type target). Grupa plików jednostkowych, które mają zostać załadowane z celem, jest umieszczana w targetname.target.wantskatalogu. To tylko katalog pełen dowiązań symbolicznych (lub realnych). Jeśli [Install]sekcja mówi, że jest , ale jeśli dowiązaniem do niego nie istnieje w katalogu, to nie będzie ładować. Kiedy systemowe generatory jednostek dodają plik jednostki do pamięci podręcznej drzewa zależności podczas rozruchu (możesz ręcznie uruchomić generatory za pomocą ), automatycznie wie, gdzie umieścić dowiązanie symboliczne - w tym przypadku w kataloguWantedBymulti-user.targetmulti-user.target.wantssystemctl daemon-reload/etc/systemd/system/multi-user.target.wants/ powinieneś to włączyć.

Kluczowe punkty instrukcji:

Dodatkowe jednostki mogą zostać załadowane do systemd („połączone”) z katalogów spoza ścieżki ładowania jednostek. Zobacz komendę link dla systemctl (1).

W obszarze systemctl poszukaj poleceń pliku jednostkowego

Ścieżka ładowania pliku jednostki

Pliki jednostek są ładowane z zestawu ścieżek określonych podczas kompilacji, opisanych w dwóch poniższych tabelach. Pliki jednostek znalezione we wcześniej wymienionych katalogach zastępują pliki o tej samej nazwie w katalogach niższych na liście.

Po ustawieniu zmiennej $SYSTEMD_UNIT_PATHzawartość tej zmiennej zastępuje ścieżkę ładowania jednostki. Jeśli $SYSTEMD_UNIT_PATHkończy się pustym komponentem („:”), zwykła ścieżka ładowania jednostki zostanie dołączona do zawartości zmiennej.

Tabela 1 i Tabela 2 z man systemd.unitsą dobre.

Załaduj ścieżki podczas działania w trybie systemowym ( --system).

• /etc/systemd/system Konfiguracja lokalna
• /run/systemd/system Jednostki czasu wykonywania
• /usr/lib/systemd/system Jednostki zainstalowanych pakietów

Ścieżka ładowania podczas działania w trybie użytkownika ( --user)

Istnieje różnica między jednostkami użytkownika i jednostkami użytkowników globalnych .

Zależny od użytkownika

• $XDG_CONFIG_HOME/systemd/user Konfiguracja użytkownika (używana tylko, gdy $XDG_CONFIG_HOMEjest ustawiona)
• $HOME/.config/systemd/user Konfiguracja użytkownika (używana tylko, gdy $XDG_CONFIG_HOMEnie jest ustawiona)

• $XDG_RUNTIME_DIR/systemd/user Jednostki czasu wykonywania (używane tylko, gdy $XDG_RUNTIME_DIRjest ustawione)

• $XDG_DATA_HOME/systemd/user Jednostki pakietów, które zostały zainstalowane w katalogu domowym (używane tylko, gdy $XDG_DATA_HOMEjest ustawione)

• $HOME/.local/share/systemd/user Jednostki pakietów, które zostały zainstalowane w katalogu domowym (używane tylko, gdy $XDG_DATA_HOMEnie jest ustawione)

--global (wszyscy użytkownicy)

Jednostki, które dotyczą wszystkich użytkowników - co oznacza również, że są własnością każdego użytkownika. Dlatego każdy użytkownik może zatrzymać te usługi, nawet jeśli administrator włączy je podczas uruchamiania.

• /etc/systemd/user Konfiguracja lokalna dla wszystkich użytkowników ( systemctl --global enable userunit.service)
• /usr/lib/systemd/user Jednostki pakietów, które zostały zainstalowane ogólnosystemowo dla wszystkich użytkowników
• /run/systemd/user Jednostki czasu wykonywania

Szara strefa

Z jednej strony Standard hierarchii plików określa, że ​​dotyczy /etcto konfiguracji lokalnych, które nie wykonują plików binarnych. Z drugiej strony określa, że /usr/local/„jest do użytku administratora systemu podczas lokalnej instalacji oprogramowania”. Można również argumentować (choćby nie tylko w celu organizacji), że wszystkie pliki jednostek systemowych powinny zostać zmniejszone /usr/local/lib/systemd/system, ale jest to przeznaczone dla plików jednostek, które są częścią „oprogramowania”, a nie menedżera pakietów. Odpowiadające im systemowe jednostki użytkownika, które są ogólnosystemowe, mogą ulec obniżeniu /usr/local/lib/systemd/user.

/etc/systemd/systemgdzie można umieścić swoje skrypty, pacman stawia pakiet skryptów /usr/lib/systemd/system.

Wydawanie systemctl enable foo.servicetworzy dowiązania symboliczne od /usrdo /etc. Aby uzyskać więcej informacji, zobacz sekcję Ścieżka obciążenia jednostki man systemd.unit(5).

Napisałem 3, jeden za drugim ntpd, jeden za drugim, statyczną kartę ethernetową i jeden do uruchamiania p0f, pasywny identyfikator systemu operacyjnego. Włożyłem je wszystkie /etc/systemd/system. Wygląda na to, że mógłbym pozwolić systemdsobie na obsługę NTP, ale nie sądzę, żebym tak bardzo na tym polegał.