Используйте сервисный модуль вместо монтируемого.

Простой сервисный модуль с одним выстрелом с командой mount работал для моего варианта использования перемонтирования (и я предполагаю, что он сработает для вашего).

Учитывая, что средства монтирования часто уже определены в / etc / fstab , а systemd автоматически сгенерировал .mount для записей fstab, есть два подхода:

1. Просто вернитесь к стандартному сервисному модулю вместо модуля монтирования и напрямую управляйте командой монтирования.
2. Попытаться использовать переопределение systemd? (Не тестировалось, не думаю, что это жизнеспособно)
   • У монтируемых модулей есть строгое требование, чтобы юниты назывались в соответствии с точкой монтирования, поэтому, вероятно, невозможно запустить два отдельных монтирования юниты для той же точки монтирования (уже отмечалось в вопросе).
   • Следовательно, это, вероятно, не сработает для повторного монтирования, если предположить, что это только переопределяет исходное определение модуля монтирования, сгенерированное из fstab, и не будет выполняться дважды.
   • Если попытаться сделать это, более вероятно, что исходное монтирование не удастся, учитывая, что параметр повторного монтирования применен к чему-то еще не смонтированному.

Пример

Мне нужно было что-то подобное, и я столкнулся со следующей проблемой при попытке использовать тип модуля монтирования systemd (потому что я не определил имя файла модуля в соответствии с точкой монтирования):

Where= setting doesn't match unit name. Refusing.

Учитывая привязку монтирования к каталог данных с большим пространством, но с родительской точкой монтирования, имеющей nosuid и nodev, мне нужно было добавить привилегии suid и dev для lxc в / var / lib / lxc.

Файл служебного модуля / etc / systemd / system / lxc-remount.service :

[Unit]
Description=Remount the /var/lib/lxc folder with suid and dev privileges
Requires=var-lib-lxc.mount
After=var-lib-lxc.mount
Before=lxc.service

[Service]
Type=oneshot
ExecStart=/bin/mount -o remount,rw,suid,dev,relatime,discard,data=ordered /var/lib/lxc

[Install]
WantedBy=lxc.service

Команды для его выполнения:

$ sudo systemctl daemon-reload
$ sudo systemctl enable lxc-remount.service
Created symlink from /etc/systemd/system/lxc.service.wants/lxc-remount.service to /etc/systemd/system/lxc-remount.service.
$ sudo systemctl start lxc-remount.service

Технически возможно реализовать это поверх systemdузлов крепления. Поэтому я не могу просто ответить «нет». У этого подхода есть несколько недостатков.

С другой стороны, вы можете выполнить все требования, кроме «использовать единицы монтирования systemd», выполнив часть перемонтирования с помощью команды mount. Обратите внимание, что systemdобычно вполне устраивает людей, использующих команду mount. Например, если вы временно размонтируете файловую систему с помощью umount, единица монтирования systemd будет помечена как inactive. И когда вы используете mountдля монтирования файловой системы вручную, systemd создает для нее временную единицу монтирования. (Обратите внимание, что при этом не создается модульный файл).

Поэтому на практике я бы рекомендовал использовать команду mountдля выполнения операций перемонтирования.

Если вы читаете этот вопрос и у вас есть дополнительная причина не использовать команду mount, задайте новый вопрос с конкретной причиной. Не зная какой-либо такой причины, я не могу рекомендовать использовать описанный ниже метод. Он представлен только в образовательных целях.

Необходимо изменить настройку Options=монтируемого устройства, а затем systemctl reloadмонтируемого устройства.

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

Однако это не очень "чисто". По-прежнему существует риск того, что ваши команды будут прерваны частично -,а можно было оставить устаревшую конфигурацию в два места -состояние монтирования в ядре и состояние монтирования в systemd. Первая проблема все равно будет существовать при использовании mount. Но это означает, что вы можете решить первую проблему и забыть о второй проблеме. Тогда вторая проблема может позже вызвать много путаницы.

Обратите внимание, что когда вы создаете перетаскивание -в файле или редактируете файл модуля, вам также нужно будет запустить systemctl daemon-reload, чтобы подобрать новое значение Option=, прежде чем вы перезагрузите модуль монтирования.

Это вторая проблема. -Я бы не рекомендовал использовать это, по крайней мере, сейчас. systemctl daemon-reload— несколько тяжеловесная операция :-). Это также может иметь нежелательные побочные -эффекты, если вам не повезет. В какой-то момент был добавлен некоторый код для перезагрузки отдельного файла модуля, но я пока не вижу, чтобы это было задокументировано как полезная функция.

(Я также заметил, что один из каталогов специальных модулей /run/systemd/system.control/описывается как «временная конфигурация, созданная с использованием API dbus». Я полагаю, что это используется для отслеживания изменений в настройках управления ресурсами и некоторых других. Я думаю, что это частные случаи, которые можно изменить с помощью systemctl --runtime set-property. Я предполагаю, что они не требуют полной перезагрузки ).