Systemd nofail? NO! FAIL!

а вот пользовался бы ты дистром с инит-скриптами, такой фигни бы не было

капает за шиворот с расплавленого от systemd стула

Стул, в данном случае, термин медицинский?

Virtualbox

используй KVM. тогда никаких поблем с systemd не будет

используй KVM. тогда никаких поблем с systemd не будет

systemd, запущенный в KVM, понимает другие опции монтирования? O_o

по ссылке ходил?

там проблема в том, что /sbin/mount.vboxsf не умеет в nofail

врёти

Мне конечно сейчас напишут, что проблема в virtual box guest additions, но какого хрена nofail передается vboxsf, если это чисто опция systemd?

там проблема в том, что /sbin/mount.vboxsf не умеет в nofail

И поэтой причине системдэ не работает? Чудная система инициализации.

как это systemd не работает? он говорит, что не может смонтировать потому что mount не знает про nofail для этой фс.

как это systemd не работает?
cslocal systemd[1]: Mounting /home/cornerstone...

Если-бы это был / или /usr какой-нибудь, тогда понятно что не загрузится. Но тут подкаталог хомяка, без systemd в консоле появится ошибка, что монтирование не удалось и система нормально загрузится. Так что все верно - не работает.

как это systemd не работает?

Систему загрузить не смог, значит не работает.

systemd не обладает телепатией и не знает насколько важна эта точка монтирования для системы.

Они могли бы это сделать и без введения новых опций монтирования.

Только при чем тут systemd, если оркаловский драйвер не умеет nofail?...

При том, что до systemd не было никакой опции nofail. Это не есть стандартная опция монтирования, это чисто systemd фича.

Что, правда? Как много нам открытий чудных...

http://linux.die.net/man/8/mount

Поиск по странице, думаю, осилишь.

4.2
nofail был до появления systemd

http://www.eazynet.de/nofail_option_in_etc_fstab
By holger at 12/25/2008 - 16:35

ps: И почему 7 лет назад у людей так не бомбило при аналогичной ситуации:

because if the partition is not available duing boot the system will boot to rescue mode and you need to remove the filesystem from /etc/fstab

Более того, у тебя в баге написано:

does not support generic userspace mount options

Генерик юзерспейс, блин. Ферштейн?

А на слово systemd, как на красную тряпку, пол-ЛОРа уже сбежалось. Ничего не меняется. Поумерьте баттхёрт, господа. systemd-специфичные опции монтирования все начинаются с x-systemd и отфильтровываются перед запуском mount.

( log4tmp и вообще 2all) С ошибкой вывалился процесс mount, хотя ему были переданы корректные параметры. Так что «не работает» тут на самом деле он. Или мы не умеем в абстракцию и всегда виним самый «верхний» компонент стека ПО?

В любой непонятной ситуации вини systemd!

Ну ок, с тем, что не было я был не прав. Но какое отношение имеет

nofail
Do not report errors for this device if it does not exist.

К процессу загрузки? Я хочу, чтобы было report errors и загрузка продолжилась. Как с другими инитами.

мы не умеем в абстракцию

Не mount должен принимать решение загружаться дальше или нет.

Нет такого стандарта, который бы регламентировал способ этого «report errors». Способ реагирования остаётся на усмотрение реализации. В случае systemd выполняется переход в аварийный режим, как самый безопасный вариант. (Впрочем, invy выше по треду привёл цитату, согласно которой «с другими инитами» так тоже бывает.)

Более того, я, например, уверен, что такая реакция — единственно правильная. От строгости ещё никто не умирал. А если на абстрактном сервере чего-нибудь не примонтируется и в итоге какой-нибудь демон засрёт своими временными файлами rootfs — то сервер превратится в тыкву. Это к слову о том, что мнения различаются, и systemd как реализация вправе выбирать умолчальный вариант.

Не mount должен принимать решение загружаться дальше или нет.

Видимо, мы всё-таки не умеем в абстракцию. mount никаких решений не принимает, он лишь (некорректно) сообщает об ошибке монтирования. Решение принимает systemd. Почему именно такое — я написал выше.

Сбрасываем время в биосе и системд при загрузке выдаст нам рутовую консоль, говоря об ошибке. Очень дружественно.

Нет такого стандарта, который бы регламентировал способ этого «report errors».

Ну очевидно имеется в виду вывод сообщений в консоль и не нулевой exit code.

Способ реагирования остаётся на усмотрение реализации.

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

А если на абстрактном сервере чего-нибудь не примонтируется и в итоге какой-нибудь демон засрёт своими временными файлами rootfs — то сервер превратится в тыкву.

Лучше сразу отыквить и не загрузить хотя бы до sshd :) Даже забитый на 100% / не мешает залогинится.

Видимо, мы всё-таки не умеем в абстракцию.

Сначала ты написал, если ошибка в компоненте на нижнем уровне, то значит виноват он. Я написал, что на верхнем уровне ее вполне можно обработать, а не говорить «ну все, приехали».

Ты кажется не уловил суть. Если я правильно понял, наличие хотя бы одной записи в fstab, которую systemd не смог корректно обработать выливается в невозможность загрузиться. Я называю это плохим дизайном.

наличие хотя бы одной записи в fstab, которую systemd не смог корректно обработать выливается в невозможность загрузиться

Если хоть на одну запись mount выдаст ошибку. nofail согласно документации просто подавляет вывод ошибки в самом mount.

Нет такого стандарта, который бы регламентировал способ этого «report errors»

Есть, называется stderr.

Нет такого стандарта, который бы регламентировал способ этого «report errors»

Не ну по-моему тут подразумевается именно error code.

Ну и я об этом же.

Помню еще в 2009 году была такая же проблема, лол. Попробуй на старом дистре в фстаб несуществующий девайс указать.

Ну очевидно

Нет, не очевидно.

имеется в виду вывод сообщений в консоль

Присутствует.

не нулевой exit code.

Чей exit code? mount'а? mount всегда возвращает неноль при ошибке, независимо от nofail. Речь об обработке этого неноля.

она используется как параметр, контролирующий загрузку.

Нет. Она выбирает тип зависимости (жёсткая/мягкая), создаваемой внутри systemd между промежуточной целью «монтирование локальных ФС» и юнитом, монтирующим данную ФС. По умолчанию — ещё раз, по умолчанию — это по цепочке приводит к переходу в аварийный режим. Потому что better safe than sorry.

Лучше сразу отыквить и не загрузить хотя бы до sshd

Это уже проблемы админа. У меня на всех машинах sshd и поднятие сети добавлены в список юнитов аварийного режима. Совершенно штатным образом, кстати говоря.

можно обработать

Можно обработать. Никто и не спорит.

Читай сообщение выше. Чей error code? Инита?

Читай сообщение выше. Это приводит к активации цепочки обработчиков, последний из которых по умолчанию настроен на выход в аварийный режим. Это можно назвать «плохими дефолтами» (хотя я не согласен), но никак не «плохим дизайном».

Где? В ините stderr? И кто его прочтёт? Более того — нет, нигде не сказано, что «report errors by printing a message to stderr and continuing boot».

Гм. Если всё по-умолчанию вываливается в error, то это таки плохой дизайн. Я не хочу бороться с системой на каждый чих.

Я его прочту, кто же ещё? Или systemd не умеет логировать загрузку?

По умолчанию — ещё раз, по умолчанию — это по цепочке приводит к переходу в аварийный режим. Потому что better safe than sorry.

сразу видного крупного админа локалхоста

демон засрёт своими временными файлами rootfs

sshd и поднятие сети добавлены в список юнитов аварийного режима

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

В реальном продакшене нужна гарантия загрузки в первую очередь, а не мнение очкастика о том, «как правильно».

Плюсую. Если у меня не примонтировалась NFS, это может означать всего-навсего подвисший DNS. Это не повод не грузиться.

С каких пор умолчальный конфиг имеет отношение к хорошему/плохому дизайну?

Хватит шланговать. Нужна гарантия загрузки в стиле «и пофиг на всё» — меняешь тип зависимости на мягкую. Это настраивается. А если ты не читаешь маны и не проверяешь стандартные конфиги перед тем, как пускать что-то в продакшен — хреновый из тебя админ.

Баг висит, танк горит, системд рулит! :)

Тебе уже рассказали, что ты сам дурак? Если нет, то я скажу: ты дурак, а SystemDick божественна!

P. S.: засирание rootfs было приведено как самый очевидный пример. Потенциальных сценариев факапа при случайно непримонтировавшейся ФС бесконечное количество. Думаю, как админ ты это понимаешь.

Незагружающийся удаленный хост без ipmi кмк с лёгкостью перебивает все эти ситуации.

Чей exit code? mount'а? mount всегда возвращает неноль при ошибке, независимо от nofail.

Т.е. чтобы vboxsf правильно работал с systemd ему просто нужно игнорировать параметр nofail?

Пока сошлись на том, что во всем виноват оракл

Да.

Ну так если на этом удалённом хосте нет аварийного удалённого управления (будь то IPMI, AMT или ещё что-то), а в аварийном таргете не прописан запуск sshd и сети, — то, как мне кажется, это ССЗБ.

К дизайну автоматической системы, а не просто кода — очень давно. Чем сложнее настройка, тем больше шансов облажаться. Зачем делать себе же хуже?

Во-первых, у нас вроде речь не о сложности настройки, а (по сути) о значениях по умолчанию.

Во-вторых, ты утверждаешь, что хардкод поведения лучше? Впрочем, как бы ты ни утверждал, systemd в этом плане совершенно точно не хуже prior art'а: в том же sysvinit ты либо довольствовался поведением в стиле чёрного ящика, либо лез руками в скриптоту.

error code возвращаемый mount'ом. Если происходит ошибка он возвращает не 0, и инит это интерпретирует как ошибку. Очевдино же! nofail очевидно заставляет его возвращать 0 всегода.