Ads
Comments 29
Получается более гибкий (и наверно даже более понятный) вариант autofs.
Спасибо!
А «обычные» mount'ы свежие дистрибы уже используют по дефолту?

Через генератор из fstab'а — используют точно. Чтобы именно генерировали сами — не видел. Я пришел к тому, что часть разделов пишутся не в fstab, а в /etc/systemd/system/*.mount, чтобы не ломать систему по недоступности сети до СХД.

Вроде бы, нет. Есть генераторы (специальный фиче-хак для создания динамических юнитов, в частности, для парсинга fstab), но это всё костыли переходного периода.

В принципе, за вычетом root'а, остальное можно смело писать. С root'ом всё чуть сложнее — и вопрос взаимодействия системы с содержимым в initrd надо внимательно смотреть, потому что можно случайно с кривым конфигом после мелкого изменения остаться.

Даже просто mount-unit'ы уменьшают количество боли и печали. Например, при использовании разделов на iscsi, которые не нужны при загрузке, но нужны при работе. Если такой раздел прописан в fstab'е, а доступа к target'у нет, то большинство систем ведут себя крайне неприятно, от остановки загрузки (и не запущенного sshd) до ухода в emergency/single, что при работой с сервером по ssh крайне неприятно.

Просто меня systemd-шные mount-ы тоже боль причинили — внезапно взяли и отмонтировались:

systemd[1]: Mounting /data/ssd…
systemd[1]: Mounted /data/ssd.
systemd[1]: Unmounting /data/ssd…
umount[3616]: umount: /data/ssd: not mounted
systemd[1]: data-ssd.mount mount process exited, code=exited status=32
systemd[1]: Unmounted /data/ssd.
systemd[1]: Unit data-ssd.mount entered failed state.

Ну, тут systemd ничем помочь не может — надо смотреть почему случилось. systemctl status, или даже dmesg. Возможно, ошибка на блочном уровне, может, даже дисконнект на уровне кабеля. Или баг где-то ниже по стеку в Линуксе.

Спасибо!!! Вот есть у меня проблема, точнее была.
Мак древнейший, на нём установлен debian 8. Мак задумывался как качалка, но он не подключал внешний диск с ntfs. В fstab прописывал, всякие проги устанавливал. Они подключали раздел с какой-то ошибкой. Но как ни странно ручьями нормально монтировалось.
Сейчас прочёл статью, настроил юниты и оно работает! Неделю не работало, а теперь работает! Я очень рад. Спасибо огромнейшее за статью.

надо смотреть что за ошибка.


Я для себя давно определил, что монтировать надо по uuid (/dev/disk/by-uuid/), тогда в случае с чехардой дисков (актуально для серверов и виртуалок) не будет прикола, что sdb больше не sdb, а sdc, в свою очередь, sdc теперь sdb.

Ну я же не совсем дурак) Я по uuid и монтировал. Вот только она сначала подключалась, а потом через какое-то время отключалась и всё. Дальше только с ручного. А теперь вот всё нормально работает.

А можно сделать ещё, чтобы перед уходом системы в suspend тоже размонтировалось?

Явного метода я не нашёл, наверное, можно в suspend-target'е потребовать остановки. Но я не уверен.

Возможно глупость спрашиваю :)
А можно таким же образом смонтировать шару на самбе, но при этом ввести пароль интерактивно (т.е. у юзера запросить) при попытке доступа к дир-ии на локалхосте, куда должна смонтироваться шара?

Интерактивно — точно нет. Процессы запускаются системд отдельно от seat и не имеют доступа к пользовательской сессии.

Чисто теоретически можно было бы подумать про что-то с pam, или auth agent, но я с трудом себе представляю как это сделать.

Нагуглил systemd-ask-password, читаю…
Похоже, в этом systemd действительно пол OS найти можно :)

Да, это же набор разных кубиков для создания базового окружения, этих кубиков там выше крыши (более 70, IIRC). Правда, во многих дистрибутивах будет собрана не сильно большая часть.

В данном случае, это скорее в плюс systemd.
Доустановил systemd-gnome-ask-password-agent, запустил.
Вызвав systemd-ask-password выскакивает GUI-окно с запросом пароля.
В результате введенная строка печатается systemd-ask-password.
И вот дальше "затык". Как полученный пароль пробросить в параметры монтирования в


[Mount]
Options=...

mount-юнита не ясно. Похоже, что никак.
Тут скорее концептуально было бы красивее и проще, если б сам systemd предусматривал бы интерактивный (с задаваемым таймаутом) запрос пароля из mount-юнита с помощью специальной директивы. Увы, я таковой не обнаружил.

Эх, вот если бы это счастье ещё и template-илось (кучка шар на одном сервере). Но увы.


Ну и да, интересный вопрос как жить с асинхронными суспендами/выключениями сервера/клиента.

А в чем проблема с использованием template unit'ов? Если в instance name можно запихать немного, то в EnvironmentFile вполне лезет почти всё, что нужно

Тогда извините, не обратил внимания, что эта фича недоступна. Остаются генераторы, можно генерировать unit'ы в /run/systemd/system

Кстати, да, generator, который делает automount для каждого mount-юнита — это интересно.

С суспендами живёт замечательно, никак не хуже autofs.


Жаль только что каждые TimeoutIdleSec секунд на каждую смонтированную и занятую кем-то шару в журнал плюется сообщение о невозможности отмонтировать. Да и на успешное монтирование/отмонтирование журнал забивается.


Кто нибудь решал такую проблему или это надо в апстрим идти?

Что-то не хочет у меня это всё нормально работать с bind-ами.

Есть /mnt/sda, с automount. Монтируется при обращении.
Есть /opt/oh2 == bind to /mnt/sda/oh2 тоже с automount, BindsTo/After/PartOf на mnt-sda.mount.

При запуске opt-oh2.automount всё первый раз срабатывает. Но! Если отмонтируется /mnt/sda, то opt-oh2.automount переходит в 'inactive(dead)' и, соответственно, перестаёт работать. А OnFailure у automount нет…

Несколько дней гугления и вопрос на «Тостере» пока результат не дали :(
Выглядит как баг. Сконструировать минимальный кейс и заслать в багтрекер: https://github.com/systemd/systemd/issues
Для этого надо чуть более вменяемое описание зависимостей (Requires/Whants/BindsTo/PartOf), чем то, что лежит на freedesktop.org. Потому как я до конца не понимаю, как это вообще должно работать — как-то после «BindsTo несколько более строгое, чем Requires» и почти то же самое про PartOf, образуется равномерная каша в голове, не разбавляемая даже экспериментами.

Повожусь ещё несколько вечеров и либо буду сочинять баго-реквест, либо плюну и откачусь на симлинки…

Огорчает, что нет готового механизма «пнуть зависимых при изменении статуса» на случай _запуска_ .mount/.automount, только на случай его остановки :(
Лучше багрепорт. PartOf — отличная штука, если в ней есть дырки, то их лучше починить, чем плюнуть и забить.
Вдогонку из лога:

// #systemctl status mnt-bind_a.automount
...
Active: inactive (dead)
...
авг 02 23:54:24 x240 systemd[1]: Set up automount Test bind 1 auto.
авг 02 23:54:33 x240 systemd[1]: mnt-bind_a.automount: Got automount request for /mnt/bind_a, triggered by 24597 (mc)
авг 02 23:55:45 x240 systemd[1]: Unset automount Test bind 1 auto.

Вот, нижняя строчка вылезает при (авто-) отмонтировании «родителя»
Only those users with full accounts are able to leave comments. Log in, please.