Re: [devel] systemd & проблемы с mount блокируют загрузку

["Денис Смирнов" <mithraen@freesource.info>]

[-- Attachment #1: Type: text/plain, Size: 6221 bytes --]

On Wed, Aug 06, 2014 at 08:47:21PM +0400, Alexey Shabalin wrote:

> Я уже высказывал своё мнение раньше по поводу  невозможности
> смонтировать раздел (кстати навряд ли это вызывает "массовое неприятие
> systemd у пользователей").
> Если у меня, по каким-либо причинам, не смонтируется /var/backup, и я
> об этом не узнаю сразу, то это будет означать что все бэкапы улетят в
> другой раздел, и сколько времени будет работать сервер до окончания
> свободного места на /var спрогнозировать невозможно. Еще большей
> проблемой будет смержить эти бэкапы в место, специально
> предназначенное для этого.

1. У серверов и рабочих станций существенно разыне требования по этому
поводу. А также разные требования к уровню компетенции.

Сейчас штатная ситуация -- на десктопе при установке был подключен некий
диск (и была автоматом создана запись в fstab). После установки диск
отключили -- и, упс, система больше не грузится.

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

Итог: это решение одна из причин того, что десктопные сборки ALT Linux с
systemd непригодны для домашнего использования людьми без компетенции
системного администратора.

2. Для сервиса выполняющего backup добавь RequiresMountsFor=/var/backup в unit.
Тогда сервис не запустится.

3. О юнитах в состоянии 'failed' стоит уведомлять администратора по почте.

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

Особенно с учетом того, что ни одного из своих серверов за последние годы
я ни разу не видел. Мало того, частенько я даже не знаю где они физически
расположены, и ETA появления около них человека, способного запустить
systemd emergency или хотя бы init=/bin/sh, диагностировать проблему и
залатать ее хотя бы до уровня "systemd позволяет нам загрузиться"
измеряется _днями_. 

5. В нашем systemd сломан crash shell -- он не позволяет залогиниться. Так
что если что-то сломалось, то без emergency mode (о котором надо еще
знать, и найти об этом информацию в гугле -- что сложно сделать при
незагружающемся компьютере) запуститься невозможно вообще.

⇒ для меня текущая ситуация с загрузкой является blocker'ом, гарантирующим
отказ от использвоания systemd где-либо, кроме моей личной домашней
машины.

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

Есть проблемы приносящие проблемы немедленно, а есть те, что приносят их в
потенциальном будущем.

Система не должна создавать первых. А решение вторых -- забота средств
мониторинга.

systemd очень гибкая штука, которая позволяет частично взлететь даже при
существенных поломках системы. И при этом разграничить сломанное и
работающее. Не надо превращать systemd в windows.

На Linux машине root всегда прав. И ни одна слишком умная софтина не имеет
никакого права отказывать мне в доступе -- как локальном, так и удаленном,
если только я сам её об этом не попросил.

P.S. Всегда можно создать еще некий strict-fs.target, который будет
disabled по-умолчанию. И который будет Requires=local-fs.target и
Before=basic.target. И достаточно будет его включить, чтобы вернуть
нынешнее поведение.

Однако эта чудесная багофича должна быть как минимум отключаемой, если не
отключенной по-умолчанию.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]