Я прочитав, що є дві папки для одиничних файлів (не в режимі користувача).

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

Конфліктуючи з цим розумінням, є така відповідь: https://unix.stackexchange.com/a/47715/33386 . Чи може хтось заповнити відсутні дані, щоб я зрозумів, що відбувається? ( ОНОВЛЕННЯ: Відповідь оновлена, і моє розуміння більше не суперечить їй. )

Крім того, схоже, що сценарії організовані в підпапки в межах /etc/systemd/system/папки:

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

В іншому місці я прочитав, що є інші місця. Здається, це стосується конкретних користувачів.

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

Оновлення 2015-08-31:

Заради інших, ось посилання на пов’язане з цим питання, яке я нещодавно запитав: Де розміщувати сценарії, виконані системними одиницями?

Найкраще розмістити файли системного блоку: /etc/systemd/system Просто додайте ціль у розділ [Встановити], читайте "Як це знати?" для деталей. ОНОВЛЕННЯ : /usr/local/lib/systemd/systemінший варіант, прочитайте "Сіру область" для деталей. "

Найкраще розмістити файли одиниць користувача : /etc/systemd/user або $HOME/.config/systemd/user це залежить від дозволів та ситуації.

Правда полягає в тому, що систематизовані одиниці (або як їх називає вступне речення, "конфігурації одиниць") можуть переходити куди завгодно - за умови, що ви готові робити ручні символьні посилання і вам відомо про застереження. Це полегшує життя, щоб розмістити пристрій там, де його systemctl daemon-reloadможна знайти з певних вагомих причин:

• Використання стандартного розташування означає, що системні генератори знайдуть їх і полегшать їх для включення під час завантаження systemctl enable. Це відбувається тому, що ваш пристрій автоматично буде доданий до дерева залежності одиниці (кеш одиниці).
• Не потрібно думати про дозволи, тому що лише визначені права користувачі можуть писати у визначені області.

Звідки це знати?

І як саме systemctl enableвідомо, де створити симпосилання? Ви жорстко кодуєте його в самому підрозділі під [install]розділом. Зазвичай є така лінія, як

[Install]
WantedBy = multi-user.target

що відповідає заздалегідь визначеному місці у файловій системі. Таким чином, systemctlвідомо, що цей блок залежить від групи одиничних файлів під назвою multi-user.target("target" - термін, який використовується для позначення груп залежностей одиниць. Ви можете перелічити всі групи systemctl list-units --type target). Група файлів одиниць, що завантажуються ціллю, поміщається в targetname.target.wantsкаталог. Це просто каталог, повний символьних посилань (або реальна річ). Якщо ваш [Install]розділ говорить , що це , але якщо символічна посилання на нього не існує в каталозі, то він не буде завантажуватися. Коли генератори системних одиниць додають ваш файл одиниці до кешу дерева залежностей під час завантаження (ви можете вручну запускати генератори за допомогою ), він автоматично знає, куди поставити символьне посилання - у цьому випадку в каталогWantedBymulti-user.targetmulti-user.target.wantssystemctl daemon-reload/etc/systemd/system/multi-user.target.wants/ якщо вам це потрібно.

Основні моменти в посібнику:

Додаткові одиниці можуть бути завантажені в systemd ("зв'язані") з каталогів, які не знаходяться на шляху завантаження одиниці. Дивіться команду посилання для systemctl (1).

Під systemctl шукайте командні файли команд

Шлях завантаження файлу блоку

Файли файлів завантажуються з набору шляхів, визначених під час компіляції, описаних у двох таблицях нижче. Файли файлів, знайдені в каталогах, перелічених раніше, замінюють файли з тим самим іменем у каталогах, що знаходяться нижче.

Коли встановлена ​​змінна $SYSTEMD_UNIT_PATH, вміст цієї змінної перевизначає одиничний шлях навантаження. Якщо $SYSTEMD_UNIT_PATHзакінчується порожній компонент (":"), до вмісту змінної буде доданий звичайний одиничний навантажувальний шлях.

Таблиця 1 та Таблиця 2 від man systemd.unitхороші.

Завантажуйте контури під час роботи в системному режимі ( --system).

• /etc/systemd/system Локальна конфігурація
• /run/systemd/system Одиниці виконання
• /usr/lib/systemd/system Одиниці встановлених пакетів

Шлях завантаження під час роботи в режимі користувача ( --user)

Існує різниця між одиницями користувачів та всіма / глобальними одиницями користувачів.

Залежно від користувача

• $XDG_CONFIG_HOME/systemd/user Конфігурація користувача (використовується лише тоді, коли $XDG_CONFIG_HOMEвстановлено)
• $HOME/.config/systemd/user Конфігурація користувача (використовується лише тоді, коли $XDG_CONFIG_HOMEне встановлено)

• $XDG_RUNTIME_DIR/systemd/user Одиниці виконання (використовуються лише тоді, коли $XDG_RUNTIME_DIRвстановлено)

• $XDG_DATA_HOME/systemd/user Одиниці пакетів, які були встановлені в домашній каталог (використовується лише тоді, коли $XDG_DATA_HOMEвстановлено)

• $HOME/.local/share/systemd/user Одиниці пакетів, які були встановлені в домашній каталог (використовується лише тоді, коли $XDG_DATA_HOMEне встановлено)

--global (всі користувачі)

Одиниці, що стосуються всіх користувачів - значить, що належать і кожному користувачеві. Таким чином, кожен користувач може зупинити ці сервіси, навіть якщо адміністратор вмикає їх під час завантаження.

• /etc/systemd/user Локальна конфігурація для всіх користувачів ( systemctl --global enable userunit.service)
• /usr/lib/systemd/user Одиниці пакетів, встановлених у всій системі для всіх користувачів
• /run/systemd/user Одиниці виконання

Сіра зона

З одного боку, Стандарт ієрархії файлів визначає, що /etcце для локальних конфігурацій, які не виконують бінарні файли. З іншого боку, він вказує, що /usr/local/"використовується для системного адміністратора при локальній установці програмного забезпечення". Ви також можете стверджувати (якщо не лише з метою організації), що всі файли системного блоку повинні підпадати під дію /usr/local/lib/systemd/system, але це призначено для файлів одиниць, які входять до "програмного забезпечення", а не від менеджера пакетів. Відповідні системні одиниці користувачів, які є загальносистемними, можуть перейти в підпорядкування /usr/local/lib/systemd/user.

/etc/systemd/systemтам, де ви ставите свої сценарії, Pacman ставить сценарії пакетів/usr/lib/systemd/system .

Видача systemctl enable foo.serviceстворює посилання від /usrдо /etc. Детальнішу інформацію див. У розділі Шлях завантаження блоку man systemd.unit(5).

Я написав 3, один для ntpd, один на другий, статичну карту Ethernet і одну для запуску p0f, пасивний ідентифікатор ОС. Я все їх поклав /etc/systemd/system. Схоже, я міг би дозволити systemdобробляти NTP-матеріали, але я не думаю, що я хочу так сильно покладатися на це.