Systemd nofail? NO! FAIL!

Во-первых, у нас речь как раз таки о сложности настройки. Настройки по-умолчанию должны быть логичным и очевидными, иначе надо лопатить весь конфиг сверяясь с man-page чтобы оно заработало как тебе нужно. И делать это каждый раз после каждого обновления, чтобы не пропустить подобной гадости.

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

Мне кажется это абсурдным. К тому же даже если vboxsf пофиксят, загрузка все равно будет обрываться, если я забуду собрать соответствующий модуль? Ну ладно. Как я понимаю, чтобы это пофиксить нужно убрать его из fstab и сделать юнит? Есть ли где-то хауту по этому и по добавлению sshd в аварийный режим? Как я понимаю, это мастхев :)

nofail очевидно заставляет его возвращать 0 всегода.

Нет.

Прочти тред. nofail интерпретируется внутри systemd и меняет тип создаваемых зависимостей с жёстких на мягкие.

Мне кажется это абсурдным.

Почему? По смыслу виноват явно mount.vboxsf. Из написанного здесь следует, что mount helper должен корректно обрабатывать наличие такого параметра. При этом очевидно, что он не должен на него никак реагировать.

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

Нет. Если пофиксят vboxsf и ты напишешь nofail, будет создана мягкая зависимость от монтирования этой ФС, и в случае ошибки монтирования загрузка будет продолжаться с варнингом.

Как я понимаю, чтобы это пофиксить нужно убрать его из fstab и сделать юнит?

Чтобы это пофиксить без исправления поведения mount.vboxsf — да, нужно написать собственный юнит (точнее, скопировать в /etc/systemd/system автогенерированный из /run/systemd/generator) и вручную добавить мягкую зависимость от local-fs.target к этому юниту.

Есть ли где-то хауту по этому

systemd(1), systemd.unit(5), systemd.service(5), systemd.mount(5), systemd.special(7), bootup(7).

и по добавлению sshd в аварийный режим

Зачем тут отдельное howto? Пишешь свой .service-юнит:

[Unit]
Description=Start emergency services
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl start --job-mode=ignore-requirements sshd.service # список можно продолжать

[Install]
WantedBy=emergency.target
WantedBy=rescue.target

И потом делаешь ему enable.

Настройки по-умолчанию должны быть логичным и очевидными

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

Ну и да — где ж ты был, когда это разрабатывалось и люди решали, каким будет дефолт?

вменяемые настройки лучше

Как выглядят эти вменяемые настройки и почему именно такие настройки (как ты приведёшь) нужно считать вменяемыми?

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

Поздравляю. Какое это отношение имеет к вопросу?

Прочти тред. nofail интерпретируется внутри systemd и меняет тип создаваемых зависимостей с жёстких на мягкие.

Но ты же понимаешь, что это противоречит тому, что происходит у топикстартера? Ведь в таком случае независимо от поведения mount (не распарсил nofail) система должна была бы загрузиться!

Кроме того это противоречит приведенному мной примеру из 2008-го года.

Хотя...

igor@adlin:~% sudo mount.ntfs -o nofail /dev/sda3 /media/OS1; echo $?
fuse: failed to access mountpoint /media/OS1: No such file or directory
21

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

У тебя вообще есть опыт работы в промышленных условиях? Если нет, то «я считаю» в твоем исполнении выглядит наивно.

Как выглядят эти вменяемые настройки и почему именно такие настройки (как ты приведёшь) нужно считать вменяемыми?

Ммм... Если что-то прямо не мешает мне загрузиться, то это может отвалиться. Я не расстроюсь из-за отвалившегося portage по сети. В данный момент он мне не нужен.

Поздравляю. Какое это отношение имеет к вопросу?

К какому вопросу?

Что противоречит? У него разве система не грузится, а не просто монтирование фейлится?

У тебя вообще есть опыт работы в промышленных условиях?

Что считать промышленными условиями?

Если нет, то «я считаю» в твоем исполнении выглядит наивно.

Давай без аргументов к личности, опыту и так далее. Я написал, почему так считаю. Если есть что возразить по существу приведённых мной доводов — возражай. Впрочем, это бессмысленный спор, ибо дело приоритетов (кому какой аспект видится важнее).

Ммм... Если что-то прямо не мешает мне загрузиться, то это может отвалиться. Я не расстроюсь из-за отвалившегося portage по сети. В данный момент он мне не нужен.

Не распарсил. Я спросил, какой способ настройки поведения ты видишь вменяемым, если хардкод — плохо, а настройка nofail'ом или редактированием юнитов — тоже плохо.

К какому вопросу?

К обсуждаемому. «Имеет ли systemd моральное право по умолчанию фейлить загрузку при неудачных монтированиях».

У него разве система не грузится, а не просто монтирование фейлится?

«Добавил я в fstab ентот ваш nofail, и... оно не грузится.»

Давай подробнее. Я не воспроизвёл.

Я интерпретировал это как «не монтируется»...

Сейчас проверил — всё грузится, просто не монтируется. Так что да, goingUp, прошу разъяснений. Действительно не грузится вся система?

Проверил только что тоже, да, с nofail грузится, но не монтируется. Значит тогда или не грузилось по другой причине, а я первым делом полез смотреть этот юнит, или я что-то напутал, сори.

Это было на opensuse какой-то 12 или 13.1 версии. Вытаскиваем батарейку из биоса, дата ставится 2004 годом. Пытаемся загрузиться и попадаем в чОрную страшную консоль. Может, есть какие настройки, отвечающие за такое поведение, но я пользовался зюзевым дефолтом. А конкретно системд не нравилось, что все файлы в системе стали «пришельцами из будущего».

батарейку то зачем. Без изнасилования компьютера в батарейку дату поменять ну никак невозможно. Понимаю. Уроки линукса. Я открою тебе секрет. Внезапно батарейка время не скинет. Время идет в отдельных часах, они энернонезависимые.

Время идет в отдельных часах, они энернонезависимые.

Что? Святым духом питаются?

У них внутри запас энергии либо в виде батареи, либо конденсатора.

Что считать промышленными условиями?

Не локалхост, вестимо :) Хотя бы несколько серверов, от которых более-менее зависит чья-то работа.

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

Вот после этого абзаца у меня и возникают сомнения относительно твоего опыта. Если монтирование того же /var является критичным для работы сервиса, это контролируют. Более того, если что-то отвалилось, админу обычно посылается письмо, на которое он реагирует. Система вставшая колом вряд-ли что-то кому-то посылает по-умолчанию, ммм?

Не распарсил. Я спросил, какой способ настройки поведения ты видишь вменяемым, если хардкод — плохо, а настройка nofail'ом или редактированием юнитов — тоже плохо.

Настройки не на том уровне делаются. Не mount'у решать, что хорошо, а что плохо. Он своё дело сделал — попытался смонтировать. Как реагировать на результат, решают выше. И по умолчанию должны решать «пущай едет дальше».

Ну он про ту самую батарейку и говорил.

Нет, не про ту. Чтобы добраться до той, что внутри часов, надо некислыми паяльными скиллами обладать. Проще контакты замкнуть, правда, надо знать какие, а для этого также нужны паяльные скиллы.

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

В чип таймера встроен собственный аккумулятор?

Таймер сбросится по ресету этого таймера перемычкой или переключателем на материнке.
Таймер сбросится после изъятия батарейки и выдержки времени, за которое успеет разрядиться конденсатор стоящий в цепи питания таймера.

В чип таймера встроен собственный аккумулятор?

Прикинь, до чего техника дошла. Только не в чип, а в модуль. Ты когда - нибудь часы CMOS видел ? Как ты думаешь, чем вызван такой их размер ?

Не локалхост, вестимо :) Хотя бы несколько серверов, от которых более-менее зависит чья-то работа.

Ну у меня есть такой опыт. Не сотни нагруженных серверов, но есть. А ещё он есть у инженеров red hat и suse.

И да, я считаю, что если админ явно не указал, что ФС не критична (nofail), то инит обязан считать, что она критична. И прекращать грузиться, а не запускать всё подряд сломя голову. Сервисы бывают разными, а их поведение, когда чего-то не хватает, ещё разнее.

Да, в убунте было по другому. Да, в systemd правильно.

Вот добавить sshd в emergency.target по дефолту, наверное, можно было бы (в дистрибутивах). Но это тоже вопрос спорный.

Плюсую.

И почему всегда так с хэйтерами. Сам не понял, что случилось, но на лоре уже нагадил.

Инженеры red hat делают деньги на саппорте :)

Если монтирование того же /var является критичным для работы сервиса, это контролируют.

Правильнее, когда такие вещи контролируются централизованно и превентивно, а не ad-hoc велосипедами в каждом сервисе.

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

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

Как реагировать на результат, решают выше.

А кто спорит-то? Блин, я пол-треда распинаюсь о том, что переход в аварийный режим — это всего лишь реакция по умолчанию.

И по умолчанию должны решать «пущай едет дальше».

Не согласен. По умолчанию в случае фейлов (которые могут иметь обширные последствия) нужно действовать консервативно. А если админу на результат данной конкретной операции насрать, он может и должен это выразить в виде атрибута nofail.

Инженеры red hat делают деньги на саппорте :)

Да. Впрочем, как и любой админ. Разница лишь в масштабе.

Нет. Разница в том, что софт, написанный шляпой, делается с оглядкой на их внедренцев :) Логика которых не всегда совпадает с общечеловеческой.

Как выясняется, логика админов тоже не всегда совпадает с общечеловеческой, да и нет её, общечеловеческой логики.

Если ред хат станет выдавать ненадёжные и непредсказуемые решения, им перестанут пользоваться. Если админ будет вводить ненадёжные и непредсказуемые сервисы, его уволят. Цели у ред хат и у админов одинаковые. Масштабы разные. Внедренцы без работы не останутся. Их нанимают не из-за сложности, а из-за перекладывания ответственности. Или если они дешевле штатных сотрудников.

Этот разговор о кровавом редхате заводился много раз, и мало кому интересен. Заинтересованные всё равно отыщут следы заговора.

уже нагадил.

vboxsf все еще не дружит с systemd. С nofail не монтируется, без nofail может привести к незагружающейся системе.

vboxsf все еще не дружит с стандартными опциями монтирования.

FXD. И виноват в этом, конечно же, systemd. Не vboxsf же.

И виноват в этом, конечно же, systemd.

Может и не виноват. Но в systemd можно сделать лучше.

Можно сделать по-другому, но по дефолту так делать не нужно. По-крайней мере мне. А у себя ты в силах все изменить.

Причем тут кровавый редхат? Они делают так, как удобно им, во многом из-за внедренцев. Я считаю такой подход неудобным и делаю иначе. Вот и вся история.

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

Я уже настроил почтовые нотификации на всех серверах одинаково. Почему я опять должен что-то настраивать? :)

Не согласен. По умолчанию в случае фейлов (которые могут иметь обширные последствия) нужно действовать консервативно. А если админу на результат данной конкретной операции насрать, он может и должен это выразить в виде атрибута nofail.
...
атрибута nofail

Я не хочу спорить насчет подхода, потому что у нас с тобой он очевидно разный. Но вот nofail это крайне плохая идея. Потому что не тот уровень абстракции.

От чего же питаются эти часы, если копм выключен из сети?

Проверил на openSUSE 13.2, больше нет такой лажи. Зато в логах journalctrl есть такое:

ноя 19 22:45:46 linux-zo3t kernel: sd 7:0:0:0: [sdc] Attached SCSI removable disk
ноя 19 22:45:46 linux-zo3t systemd-fsck[237]: /dev/sda6: Superblock last mount time is in the future.
ноя 19 22:45:46 linux-zo3t systemd-fsck[237]: (by less than a day, probably due to the hardware clock being incorrectly set)  FIXED.
ноя 19 22:45:46 linux-zo3t systemd-fsck[237]: /dev/sda6: Superblock last write time is in the future.
ноя 19 22:45:46 linux-zo3t systemd-fsck[237]: (by less than a day, probably due to the hardware clock being incorrectly set).  FIXED. 

Это при том, что дату я тогда поставил 22,05,2004

Со встроенными батарейками были dallas-ы. Но это эпоха 286-ых, край 386. Видел недавно рабочую станцию сан тех же лет с далласом.

Хотя пишут, что в первопнях ещё встречались.

Да будет тебе известно, что эти сообщения генерируются не systemd, а самым что ни на есть обычным e2fsck.

Так а в консоль меня выкидывал тогда кто? Полагаю, что не fsck.

Мне неизвестно, что было «тогда». Воспроизвести я не смог (как и ты). А сейчас ты мне показываешь совершенно нерелевантные сообщения, к которым к тому же systemd не имеет ни малейшего отношения.

Ну да, ведь моя цель оклеветать систмд любой целью. Забей. Давно было, сейчас не воспроизводится, все счастливы. Может это какие-то старые логи ( хренали стоит дата «ноя 19»?), хотя я вводил journalctl --since=2004-05-22, и системная дата тогда была выставлена 22 мая 2004.

Прикинь, до чего техника дошла. Только не в чип, а в модуль.

Модель материнки в студию, в которой батарейка встроена в чип.

Ты когда - нибудь часы CMOS видел ? Как ты думаешь, чем вызван такой их размер ?

Неужели батарейкой, которая встроена прямо в чип?

Что вообще такое cmos часы? Вы хоть понимаете, что означает эта аббревиатура?

Модель материнки в студию, в которой батарейка встроена в чип.

Строго говоря, NCR System 3350 (система) и DS1387 (чип).

Но это не отменяет того факта, что lenin386 говорит хрень и так никто уже давно не делает.

Строго говоря, NCR System 3350 (система) и DS1387 (чип).

Благодарю. Это где-то 90 годы?

Я считаю такой подход неудобным и делаю иначе.

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

По-поводу уведомлений мониторинга и т.п. Как минимум странно, что человек с опытом промышленного мониторинга серверов говорит такие вещи:

Если монтирование того же /var является критичным для работы сервиса, это контролируют. Более того, если что-то отвалилось, админу обычно посылается письмо, на которое он реагирует. Система вставшая колом вряд-ли что-то кому-то посылает по-умолчанию, ммм?

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

А теперь представь, что по незнанию, недосмотру, или просто делал другой сотрудник, который не в теме, добавили раздел с данными для веб-сервера, перенесли их туда, но не включили в мониторинг. И так всё и работало. Пока во время перезагрузки этот раздел по каким-то причинам не отвалился. Если продолжить загрузку как ни в чём не бывало, то веб-сервер запустится. Даже логины пользователей будут работать, база доступна. Только данных не будет. А может ещё и новые наплодятся. И их придётся со старыми сращивать. И мониторинг промолчит, а узнаешь ты об этом, в лучшем случае, от благодарных пользователей. А если сервер вывалился в emergency, то ты узнаешь об этом сразу.

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