Intereting Posts
поделиться существующим сеансом tmux Как узнать, есть ли у меня «чужие» пакеты в моем Linux Как определить размер блока файловой системы vxfs? Переадресация портов с помощью iptables и PIA VPN для одного пользователя Использование O_DIRECT в Linux Как сохранить один снимок рабочего стола в jpg с помощью ffmpeg? Удалить узел XML, содержащий определенный элемент Инструмент для измерения качества энтропии? Что означает «if1 @ if2» в имени интерфейса при выводе команды «ip address» в Ubuntu ssh открытый ключ auth: первый вход по-прежнему запрашивает пароль Почему sendmail работает по-разному в разных оболочках? Почему мой сетевой интерфейс работает на низкой скорости? Не удается подключиться через sshfs, потому что неправильная конфигурация в файле ~ / .ssh / config как разрешить различным пользователям одинакового доступа к группе / редактировать файлы / каталоги, созданный пользователем той же группы Как macOs учитывает использование диска

Включение «связанных» единичных файлов в Systemd

Я все еще получаю доступ к systemd и сталкивался с чем-то. Это не проблема, но я хотел бы узнать больше о том, как это происходит. Я не мог найти никакой ссылки на это в другом месте.

Во-первых, я понимаю, что файлы пользовательских модулей для служб должны идти в /etc/systemd/system . Тем не менее, было бы неплохо управлять нашими серверами, если бы файлы модулей могли находиться в другом месте.

В документации я видел, что вы можете «связывать» единичные файлы следующим образом:

 systemctl link /path/to/servicename.service 

Это создаст ссылку на выше в системе /etc/systemd/system . Теперь вы можете запустить / остановить эту услугу. На первый взгляд, это казалось хорошим способом управлять нашими услугами.

Однако попытка включить такой «связанный» единичный файл приводит к сбою:

 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 

Используя тот же самый файл, но скопированный в /etc/systemd/system а не связанный, вы получаете:

 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. 

Из этого, похоже, невозможно включить привязку в файлах модулей, которые будут вызываться при запуске системы.

Если это так, какова точка функциональности «link»? В документах говорится:

ссылка FILENAME

Свяжите файл блока, который не находится в пути поиска файла устройства, в путь поиска файла устройства. Для этого требуется абсолютный путь к единичному файлу. Эффект этого может быть отменен с отключением. Эффект этой команды заключается в том, что единичный файл доступен для запуска и других команд, хотя он не установлен непосредственно в пути поиска устройства.

Страница руководства вводит в заблуждение.

systemctl link /root/myservice.service

 systemctl enable /root/myservice.service 

Первый позволяет вам systemctl start myservice . Второе позволяет автоматически myservice (что, как указал @Julien, автоматически добавляет link ).

Я думаю … Я пытался весь день крутить вокруг себя.

При включении службы с другого пути, кроме путей по умолчанию, вы должны использовать полный путь. Enable также создаст для вас ссылку:

 systemctl enable /root/myservice.service 

После включения вы можете запустить / остановить / статус с именем службы

 systemctl start myservice 

Несколько оговорок здесь:

  • вы не можете включить служебный файл, который сам по себе является ссылкой
  • убедитесь, что путь находится на том же установленном диске. Если это не так, systemd не сможет загружать файлы сервисного модуля при загрузке, потому что диск еще не будет установлен, и файлы не будут найдены. (см. файлы привязанных файлов Systemd на смонтированном диске не загружаются )
  • из-за ошибки в systemd вы не можете разрешать экземпляры из единичного файла, который находится в нестандартном пути (см. https://github.com/systemd/systemd/issues/661 )