Таймаут systemd на разблокировку шифрованного тома

А разве x-systemd.device-timeout=1 сработает? JobTimeout= же будет тикать одновременно с таймаутом расшифровки?

Ну и да, если у тебя есть какой-нибудь графический password-agent, который можно запустить совместно с DM, то я бы скорее включил для этого раздела automount и пусть оно монтируется автоматически при логине.

x-systemd.device-timeout=1

Я не знаю, честно говоря. Сейчас при такой настройке у меня всё хорошо работает: если не введу пароль через две минуты, загрузка продолжается без проблем. x-systemd.device-timeout=1 я вычитал с archwiki:

External devices

External devices that are to be mounted when present but ignored if absent may require the nofail option. This prevents errors being reported at boot. For example:

/etc/fstab

/dev/sdg1 /media/backup jfs defaults,nofail,x-systemd.device-timeout=1 0 2

The nofail option is best combined with the x-systemd.device-timeout option. This is because the default device timeout is 90 seconds, so a disconnected external device with only nofail will make your boot take 90 seconds longer, unless you reconfigure the timeout as shown. Make sure not to set the timeout to 0, as this translates to infinite timeout.

Получается, эта опция излишня?

Забавно. Ну тогда попробуй оба варианта. Я ни разу не пользовался cryptsetup и не знаю, что там в каком порядке происходит.

Потестировал.

Во-первых, в cryptsetup нужно дописать noauto либо nofail, потому что иначе расшифровка раздела подтянется по жёсткой зависимости от cryptsetup.target и если ты не введёшь пароль, то по цепочке остановится вся загрузка. По смыслу больше подходит noauto.

Во-вторых, да, действительно, при выставлении x-systemd.device-timeout=1 на точке монтирования у тебя есть одна секунда, чтобы ввести пароль.

В-третьих, если ты не успеешь ввести пароль, ожидание устройства и монтирование в любом случае сфейлятся по зависимости от cryptsetup, т. е. лучше просто выставь x-systemd.device-timeout=0. И nofail оставь, да.

Всё вышесказанное проверено на арче с systemd 231.

Нулевой тайм-аут или infinite?

В данном случае одно и то же.

Debian Jessie, 215.

В той конфигурации, что указана в шапке, у меня есть мои две минуты на ввод разблокировочного пароля, если не ввёл - загрузка продолжается. cryptsetup.target failed из-за fail его зависимости из fstab, а она failed из-за fail systemd-cryptsetup@раздел. Тем не менее, система загрузилась. О_о.

Загадочная Debian'овская магия?

Так или иначе, получается, надо сделать так:

• добавить nofail в crypttab (noauto мне не подходит, всё ещё хочу авто-расшифровку, просто пусть не будет катастрофы, если я её не успею выполнить), чтобы systemd не делал паники из-за неудачи разблокировки тома
• оставить nofail в fstab, чтобы systemd не делал паники из-за неудачи монтирования раздела в этом томе
• оставить timeout=120 в crypttab, чтобы на разблокировку было 2 минуты
• установить x-systemd.device-timeout=0 в fstab, чтобы я был ограничен по времени только установкой timeout пунктом выше. В случае, если я не разблокирую том, монтирование в любом случае отменится из-за провала зависимости.

Ага? И ещё один вопрос про crypttab: тут (https://www.freedesktop.org/software/systemd/man/crypttab.html) упомянут помимо timeout ещё и такой же x-systemd.device-timeout. Не нужно ли мне его выставить тоже в 0?

Да, наверное, в дебиане сам cryptsetup.target подтягивается нежёсткой зависимостью.

Остальное именно так.

Последнее — это таймаут ожидания физического диска и раздела на нём. Думаю, его лучше оставить.

С nofail в crypttab меня не спрашивают о пароле во время загрузки, запрос некоторое время висит на tty1, потом исчезает в пользу собственно login. Нет ли аналога nofail, чтобы он всё-таки ждал пароля, но сделал systemd-cryptsetup@... Wanted а не Required? Так или иначе, видимо, если я уберу nofail, если я не введу пароль, то этот юнит фэйлится, фэйлится cryptsetup.target (но он Wanted, а не Required, всё хорошо), фэйлится home-user.mount (но в fstab стоит nofail, и этот юнит тоже Wanted, всё хорошо).

Нет ли аналога nofail, чтобы он всё-таки ждал пароля, но сделал systemd-cryptsetup@... Wanted а не Required?

В теории, именно таким должен быть эффект от nofail.

https://www.freedesktop.org/software/systemd/man/crypttab.html

Что-то он тут какой-то не такой.

will not wait for the device to show up and be unlocked at boot

Вот оно и не ждёт, а разблокировочный диалог оказывается Леннарт знает где.

Класс. Очень весело. Пойду заведу багу по этому поводу — не очень понятно, почему nofail отключает создание зависимостей порядка (и в crypttab, и в fstab).

In meantime, можно руками:

/etc/systemd/system/systemd-cryptsetup@<имя_тома>.service.d/ordering.conf:

[Unit]
Before=cryptsetup.target

А лучше даже так:

/etc/systemd/system/путь-до-точки-монтирования.mount.d/ordering.conf:

[Unit]
Before=local-fs.target

А чем поможет расстановка порядка? Тем, что cryptsetup.target/local-fs.target (которые явно нужны) не произойдут раньше, чем расшифровка/монтирование зафэйлятся либо завершатся успешно?

Я, наверное, пока просто уберу nofail. Волею разработчиков Debian, всё работает именно так, как мне надо: ждём разблокировки, если не дожидаемся - фэйлятся cryptsetup и монтирование, но ничто из этого не Required и идём дальше. Ну и при следующем обновлении systemd и прочего в Debian, вероятно, всё останется так же. И при всех остальных обновлениях.

Когда заведёшь багу - пожалуйста, кинь сюда ссылку, я на неё буду посматривать, интересно же.

Или мне кажется, или после этих манипуляций у меня система начала дольше выключаться. Скорее всего, мне кажется, или виноваты не эти манипуляции, но не подскажешь - чем посмотреть время выключения системы по сервисам (аналогично systemd-analyze)?

А чем поможет расстановка порядка? Тем, что cryptsetup.target/local-fs.target (которые явно нужны) не произойдут раньше, чем расшифровка/монтирование зафэйлятся либо завершатся успешно?

Да. Эти цели как раз «тормозят» загрузку до тех пор, пока не примонтируется всё, что нужно.

Когда заведёшь багу - пожалуйста, кинь сюда ссылку, я на неё буду посматривать, интересно же.

На самом деле это уже обсуждалось в systemd-devel в 2014 году. Ответ следующий: nofail нужен не для того, чтобы игнорировать существенные ошибки самого процесса монтирования/расшифровки, а для того, чтобы игнорировать отсутствие искомого устройства при загрузке. Если исходить из такой задачи, то наличие таймаута ожидания будет только мешать.

Поэтому я бы сэмулировал искомое самостоятельно: добавил бы везде noauto, а потом

systemctl add-wants cryptsetup.target systemd-cryptsetup@<имя-тома>.service
systemctl add-wants local-fs.target <путь-до-точки-монтирования>.mount

Такой тулзы вроде бы нет. Только если по логам смотреть.

В логах я вижу следующее:

авг 27 12:23:56 debian NetworkManager[604]: <info> exiting (success)
авг 27 12:23:59 debian networking[8492]: Deconfiguring network interfaces...done.
авг 27 12:23:59 debian lvm[8519]: 2 logical volume(s) in volume group "local-vg" unmonitored
авг 27 12:24:03 debian systemd-cryptsetup[8489]: Failed to deactivate: Device or resource busy
авг 27 12:24:03 debian systemd[1]: systemd-cryptsetup@home_user_decrypt.service: control process exited, code=exited status=1
авг 27 12:24:03 debian systemd[1]: Unit systemd-cryptsetup@home_user_decrypt.service entered failed state.
авг 27 12:24:03 debian systemd[1]: Shutting down.

Ситуацию понял, спасибо. Я, наверное, пока всё-таки оставлю, как есть, а потом для любых новых шифротомов придётся вспоминать, что я там делал с systemd, чтобы всё работало, как надо.

В порядке эксперимента:

/etc/systemd/system/systemd-cryptsetup@home_user_decrypt.service.d/ordering.conf:

[Unit]
Before=dev-mapper-home_user_decrypt.device

Теперь он отключаться вообще отказался. После

авг 27 12:41:13 debian lvm[1404]: 2 logical volume(s) in volume group «local-vg» unmonitored

я подождал минуту и убил принудительно.

Выше по логам (ещё в предыдущем заходе, без нового порядка) нашёл:

авг 27 12:23:55 debian systemd-logind[601]: Failed to abandon session scope: Connection reset by peer
авг 27 12:23:55 debian sshd[591]: Received signal 15; terminating.
авг 27 12:23:55 debian systemd[1]: home-user.mount mount process exited, code=exited status=32
авг 27 12:23:55 debian systemd[1]: Failed unmounting /home/user.
авг 27 12:23:55 debian systemd[744]: pam_unix(systemd-user:session): session closed for user user
авг 27 12:23:55 debian lightdm[635]: Failed to get D-Bus connection
авг 27 12:23:55 debian umount[8417]: umount: /home/user: target is busy
авг 27 12:23:55 debian umount[8417]: (In some cases useful info about processes that
авг 27 12:23:55 debian umount[8417]: use the device is found by lsof(8) or fuser(1).)
авг 27 12:23:55 debian syncthing[8194]: [QATVJ] INFO: Exiting

Я сейчас окончательно протестировать всё это не могу (раст собирается), но вырисовываются вполне логичные действия:

• в crypttab — timeout=X
• в fstab — x-systemd.device-timeout=0
• в crypttab/fstab — noauto и мягкие зависимости руками

Гм. Весело. Тогда я поэкспериментирую локально.

А вон тот syncthing — он работает с /home/user?

Работает. Я попробовал его заранее грохнуть - не помогло, при выключении хомяк всё ещё занят. Вот полный лог выключения: http://ix.io/1hnD

А чем плох текущий вариант - timeout в crypttab, x-systemd.device-timeout и nofail в fstab, и Debian-специфичный cryptsetup.taget WantedBy sysinit.target?

Debian-специфичный cryptsetup.taget WantedBy sysinit.target

Более того, он даже не Debian-специфичный. В апстриме так же, внезапно.

А чем плох текущий вариант

Ну, формально, монтирование расшифрованного тома будет идти одновременно с дальнейшей загрузкой.

Более того, он даже не Debian-специфичный. В апстриме так же, внезапно.

Ну и отлично!

Ну, формально, монтирование расшифрованного тома будет идти одновременно с дальнейшей загрузкой.

Да и пусть себе идёт, лишь бы пароль ввести дали полноценно - а без nofail так и получается. Или там есть какие-то хитрости?

А чем плох текущий вариант

А, вот! Зависимости порядка же двунаправленные! Поскольку монтирование не упорядочено относительно local-fs.target, размонтирование тоже будет выполняться чёрт-те когда, т. е. до завершения юзерской сессии. Соответственно, размонтирование обломается (что мы и видим из логов), откуда немедленно следуют эти твои задержки при отключении зашифрованного тома.

Что-то я себе плохо представляю порядок выключения и отмонтировнаия. Сейчас у меня дерево зависимостей такое:

●   │ ├─sysinit.target
●   │ │ ├─console-setup.service
●   │ │ ├─debian-fixup.service
●   │ │ ├─dev-hugepages.mount
●   │ │ ├─dev-mqueue.mount
●   │ │ ├─kbd.service
●   │ │ ├─keyboard-setup.service
●   │ │ ├─kmod-static-nodes.service
●   │ │ ├─lvm2-monitor.service
●   │ │ ├─networking.service
●   │ │ ├─proc-sys-fs-binfmt_misc.automount
●   │ │ ├─qemu-system-x86.service
●   │ │ ├─sys-fs-fuse-connections.mount
●   │ │ ├─sys-kernel-config.mount
●   │ │ ├─sys-kernel-debug.mount
●   │ │ ├─systemd-ask-password-console.path
●   │ │ ├─systemd-binfmt.service
●   │ │ ├─systemd-journal-flush.service
●   │ │ ├─systemd-journald.service
●   │ │ ├─systemd-modules-load.service
●   │ │ ├─systemd-random-seed.service
●   │ │ ├─systemd-sysctl.service
●   │ │ ├─systemd-timesyncd.service
●   │ │ ├─systemd-tmpfiles-setup-dev.service
●   │ │ ├─systemd-tmpfiles-setup.service
●   │ │ ├─systemd-udev-trigger.service
●   │ │ ├─systemd-udevd.service
●   │ │ ├─systemd-update-utmp.service
●   │ │ ├─udev-finish.service
●   │ │ ├─cryptsetup.target
●   │ │ │ └─systemd-cryptsetup@home_user_decrypt.service
●   │ │ ├─local-fs.target
●   │ │ │ ├─-.mount
●   │ │ │ ├─boot-efi.mount
●   │ │ │ ├─home-user.mount
●   │ │ │ ├─lvm2-activation-early.service
●   │ │ │ ├─lvm2-activation.service
●   │ │ │ ├─systemd-fsck-root.service
●   │ │ │ ├─systemd-remount-fs.service
●   │ │ │ └─tmp.mount

Это же зависимости требования? Я говорю про зависимости порядка.

Да, это они. А как можно легко увидеть все зависимости порядка? И почему с ними что-то настолько сильно не так?

systemctl list-dependencies --after default.target

С ними что-то не так именно из-за того, что nofail отключает расстановку зависимостей порядка. В нормальном случае файловые системы монтируются строго до того, как разрешается вход пользователей в систему:

*.mount --> local-fs.target --> systemd-user-sessions.service (разрешает вход в систему) --> session-*.scope

Стрелка A --> B означает, что юнит B имеет зависимость After=A.

Тонкость в том, что при остановке юнитов зависимости порядка учитываются в обратную сторону, т. е. в вышеописанном случае никакие файловые системы не начнут отмонтироваться, пока не умрут все session-*.scope. А в твоём случае это не так, т. к. исчезает первая стрелка в схеме выше.

Ага. В выхлопе команды я home-user.mount вообще не нашёл, суть происходящего мне теперь ясна. А если я просто уберу nofail, то у меня, вероятно, не пойдёт дальше загрузка, если не пройдёт расшифровка (тогда раздел не появится). Ага?

Да, система упадёт в emergency.target.

То есть, следует сделать именно так, как ты рекомендуешь тут? Таймаут systemd на разблокировку шифрованного тома (комментарий)

Можно попробовать. Раст всё ещё собирается :)

unknown operation «add-wants». Хехе, Debian Jessie.

Нет, так тоже не работает. От local-fs.target не создаётся зависимость порядка к точке монтирования. Вот это уже пойду и зарепорчу.

А что мне тогда делать?)

Всё то же самое, только вместо add-wants вот это.

/etc/systemd/system/cryptsetup.target.d/override.conf:

[Unit]
Wants=systemd-cryptsetup@home_user_decrypt.service
After=systemd-cryptsetup@home_user_decrypt.service

/etc/systemd/system/local-fs.target.d/override.conf:

[Unit]
Wants=home-user.mount
After=home-user.mount

Т.е. мы добавляем ещё и after, потому что зависимости порядка не создаются и при noauto. А должны были?

И ещё - а такие действия не заменят уже существующие Wants и After? Т.е. не исчезнут ли те юниты, которые в этих полях были раньше?

Рассмотри вариант перехода на gentoo. У нас такое просто делается:

# grep -vE '^#|^$' /etc/conf.d/dmcrypt 
target='data'
source='/dev/sdc1'
options='--timeout=120'

# grep data /etc/fstab 
/dev/mapper/data /mnt/data ext4 defaults,noatime,nofail 0 1

Спасибо, но я очень привык к Дебиану и мне на нем уютно.

Было бы хорошо, если бы создавались (вот бага). На самом деле в cryptsetup-юнитах создаются (но для однообразия можно написать и здесь), а в mount-юнитах нет.

Тащемта, тут всё делается ещё проще, двумя строчками в crypttab и fstab. У вас в OpenRC ведь размонтирование происходит с помощью umount/detach в цикле после убийства всех процессов, да? Так и здесь. Но ТС хочет совсем корректно. Это посложнее, да и пара багов вскрылась.

Ваня жжёт про сустемД, он нужен только ему... и Лёне, возможно они женаты.

Осталось понять, кто из них хранительница очага? Лёня или Ваня? Или обе две?

А вообще, наверное, проще будет скопировать из /run/systemd/generator сгенерированные юниты systemd-cryptsetup@home_user_decrypt.service и home-user.mount и слегка поправить их руками, чем пытаться запихнуть необычный юзкейс в семантику crypttab/fstab.

В идеале, конечно, это делается одной опцией nofail (как у Lavos в его генте/OpenRC), но у systemd достаточно странная интерпретация этой опции, поэтому вариант nofail с правильной (нужной нам) семантикой приходится эмулировать через ручное выписывание зависимостей Wants=/After=.

А как ты посоветуешь поправить сгенерированные юниты?