Автомонтирование файловых систем с systemd

[MagicGTS]

Получается более гибкий (и наверно даже более понятный) вариант autofs.
Спасибо!

[pansa]

А «обычные» mount'ы свежие дистрибы уже используют по дефолту?

[grossws]

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

[nazarpc]

В Ubuntu оно не работало у меня некоторое время назад и исправлять никто не спешит: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1617512

[amarao]

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

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

[grossws]

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

[pansa]

Просто меня 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.

[amarao]

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

[bano-notit]

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

[nikitasius]

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

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

[bano-notit]

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

[yktoo]

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

[amarao]

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

[bormental]

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

[amarao]

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

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

[bormental]

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

[grossws]

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

[bormental]

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

[Mount]
Options=...

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

[evg_krsk]

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

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

[grossws]

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

[evg_krsk]

В том что (https://www.freedesktop.org/software/systemd/man/systemd.automount.html):

Note that automount units cannot be templated, nor is it possible to add multiple names to an automount unit by creating additional symlinks to its unit file.

Как вы предлагаете использовать EnvironmentFile для подстановки разных What/Where, что-то не очень понял.

[grossws]

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

[amarao]

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

[evg_krsk]

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

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

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

[av0000]

Что-то не хочет у меня это всё нормально работать с 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 нет…

Несколько дней гугления и вопрос на «Тостере» пока результат не дали :(

[amarao]

Выглядит как баг. Сконструировать минимальный кейс и заслать в багтрекер: https://github.com/systemd/systemd/issues

[av0000]

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

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

Огорчает, что нет готового механизма «пнуть зависимых при изменении статуса» на случай _запуска_ .mount/.automount, только на случай его остановки :(

[amarao]

Лучше багрепорт. PartOf — отличная штука, если в ней есть дырки, то их лучше починить, чем плюнуть и забить.

[av0000]

Вдогонку из лога:

// #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.

Вот, нижняя строчка вылезает при (авто-) отмонтировании «родителя»