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

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

Ради других, вот ссылка на связанный с этим вопрос, который я недавно задавал: куда я помещаю сценарии, выполняемые модулями systemd?

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

Лучшее место для размещения файлов пользовательских модулей: /etc/systemd/user или, $HOME/.config/systemd/user но это зависит от разрешений и ситуации.

Правда состоит в том, что юниты systemd (или, как их называет во вступительном предложении «конфигурации юнитов») могут находиться где угодно - при условии, что вы готовы создавать ручные символические ссылки и знаете о предостережениях. Это облегчает жизнь, чтобы поместить устройство туда, где systemctl daemon-reloadможно найти его по нескольким причинам:

• Использование стандартного местоположения означает, что генераторы systemd найдут их и упростят их включение при загрузке systemctl enable. Это потому, что ваш юнит будет автоматически добавлен в дерево зависимостей юнитов (кеш юнитов).
• Вам не нужно думать о разрешениях, потому что только правые привилегированные пользователи могут писать в назначенные области.

Как это узнать?

А как именно systemctl enableузнать, где создать символическую ссылку? Вы жестко закодируете его в самом модуле под [install]разделом. Обычно есть такая строка

[Install]
WantedBy = multi-user.target

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

Ключевые моменты в руководстве:

Дополнительные модули могут быть загружены в systemd («связаны») из каталогов, которые не находятся на пути загрузки модулей. Смотрите команду link для 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)

Существует разница между единицами измерения пользователя и единицами измерения всех / глобальных пользователей.

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, но я не думаю, что хочу так сильно на это полагаться.