telnet отказывается подключаться, когда /bin привязан к другому местоположению
РЕДАКТИРОВАТЬ:Оказывается, мой первый подход не работал должным образом. Раздел [Install]в файле переопределений на самом деле не работает, а RequiresMountsFor=работает только для монтирований, объявленных в fstab. Поэтому я предлагаю альтернативу, которая позволит достичь тех же результатов, но с использованием других директив.
Чтобы предотвратить запуск устройства, если не смонтирован том /media/Elements, используйте директиву ConditionPathIsMountPoint=, которая проверит это и предотвратит запуск устройства, если этот каталог не смонтирован.
# /etc/systemd/system/transmission.service.d/override.conf
[Unit]
ConditionPathIsMountPoint=/media/Elements
(ПРИМЕЧАНИЕ. :Вы можете использовать команду systemctl edit transmission.service, чтобы открыть редактор этого файла переопределений.)
Чтобы инициировать запуск transmission.serviceпри каждом монтировании USB, вам необходимо добавить к нему символическую ссылку в каталог .wants/для устройства монтирования. (В идеале об этом должен позаботиться раздел [Install], но, похоже, это не работает из файла переопределений.)
Создайте его вручную с помощью этих двух команд:
$ sudo mkdir -p /etc/systemd/system/media-Elements.mount.wants/
$ sudo ln -sf /lib/systemd/system/transmission.service /etc/systemd/system/media-Elements.mount.wants/
После этого установите /media/Elementsи посмотрите, как начинается передача...
Оригинальный ответ ниже...
Таким образом, директиваAfter=влияет только на упорядочение, если оба юнита стоят в очереди на запуск, то этот будет запущен после завершения другого, но не инициирует запуск другого. Для этого вам нужно Requires=.
Но для скакунов вRequiresMountsFor=есть удобный ярлык, который может использовать скакунов как пути.
Возможно, вы также захотите настроить это так, чтобы данное устройство запускалось при подключении USB-накопителя. Вы можете активировать это, используяWantedBy=(в секции [Install])и ссылаясь на устройство .mountотсюда. После настройки и использования systemctl enableдля создания отношения «Wanted» запуск этого устройства будет (также )при подключении USB-накопителя (, если это будет сделано позже, а не во время загрузки вверх.)
Собираем все воедино:
# /etc/systemd/system/transmission.service.d/override.conf
[Unit]
RequiresMountsFor=/media/Elements "/media/Vault 13" "/media/Black Mesa"
[Install]
WantedBy=media-Elements.mount
WantedBy=media-Vault\x2013.mount
WantedBy=media-Black\x20Mesa.mount
А затем включите этот блок, который будет создавать символические ссылки в каталогах *.mount.wants/(точные имена символических ссылок будут напечатаны в systemctl enableвывод):
# systemctl enable transmission.service
Это должно позаботиться об этом.
Мне непонятно, почему вы перечисляете три монтирования, поскольку в тексте вопроса вы предполагаете, что только /media/Elementsиспользуется для хранения загрузок Transmission... Если это действительно так, вы, вероятно, могли бы удалить другое два и оставить только ссылки на "Элементы".
(ПРИМЕЧАНИЕ.:Я не проверял все это перед публикацией, но я вполне уверен, что это сработает. Если по какой-то причине это не так, оставьте мне комментарий с более подробной информацией, я буду рад работать с вами, чтобы понять это.)
Я разобрался со своими проблемами. Итак, прежде всего, как я уже упоминал, я не смог повторно подключиться с помощью telnet. Кажется, это потому, что есть родительский процесс, который контролирует команды busybox и telnet. Когда я пытаюсь создать другой процесс telnetd на переднем плане, я получаю следующую ошибку.
$ telnetd -F
telnetd: bind: Address already in use
Сначала я проверил процесс, который использует порт 23, который является портом по умолчанию для telnetd:
$ netstat -lntup | grep 23
tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN 2697/agent
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 362/pc
Таким образом, привязка /binпапки к другому местоположению приводит к путанице в процессе pc. В результате он не может создавать сеансы telnetd и занимает порт 23. Поскольку этот процесс отвечает за большинство конфигураций только при загрузке. Единственный раз, когда я видел, что этот идентификатор процесса был убит, - это когда начинается процесс обновления прошивки. Тем не менее, я убил процесс и перезапустил telnetd.
$ kill -9 362
$ telnetd
Теперь это работает, но это уродливый патч, поэтому я использовал другой подход. Конечно, запуск telnetd на другом порту возможен, но я решил вообще не привязывать папку /bin.
Я решил добавить место монтирования перед путем. Таким образом, каждая команда busybox, которую я запускал, находилась в смонтированном месте. Потому что впервые в PATH найдена команда, которая будет выполнена. Таким образом, наличие нескольких busybox в пути не повредит. Предполагая, что у меня есть новый busybox в/mnt/<device-id>/bin:
$ for i in `./busybox --list`; do ln -s busybox $i; done
$ PATH=/mnt/<device-id>/bin:$PATH
Теперь все новые команды busybox работают должным образом. Привязка больше не нужна, и системный процесс больше не убивается.
В качестве примечания я упомянул в своем сообщении с вопросом, что мне не удалосьumount/binпапку. Видимо, причина этого была именно такой, как я думал. Использование другого экземпляра busybox фактически отменяет привязку папки /bin.