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

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

[Денис Смирнов]

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

У нас сейчас с systemd есть проблема. Одна из тех, что вызывает массовое
неприятие systemd у пользователей.

Суть проблемы: при невозможности смонтировать любой из разделов
упомянутый в /etc/fstab система останавливает загрузку, и далее уже
требуются специальные знания для восстановления работоспособности системы.

Причем проблема одинаково воспроизводится при невозможности смонтировать,
к примеру /usr и какой-нибудь /home/user/films или /media/films.

Предлагаю следующее решение и прошу комментариев.

Зависимости на смонтированные FS
================================

Сейчас монтирование *всех* разделов упомянутых в /etc/fstab происходит до
собственно запуска большинства сервисов -- ибо они имеют зависимость на
basic.target, который зависит от local-fs.target, которая зависит от
монтирования всех разделов из /etc/fstab.

В systemd есть встроенный метод делать зависимости конкретных сервисов на
смонтированные FS: RequiresMountsFor.

Для сервисов, которые имеют эту директиву в unit-файле зависимость на
local-fs.target не требуется. Однако прописывать ее корректно всем
мантейнерам было, есть и будет лень и некогда.

Решения:

1. Нам никто не мешает сгенерировать её автоматически, еще на этапе сборки
rpm-пакета: мы можем автоматически добавить в нее все каталоги,
присутствующие в собираемом пакете.

Насколько я понял, для этого нужно просто создать соответствующий
/usr/lib/rpm/fixup-(something)?

2. Для SYSV скриптов предлагаю оставить то поведение, которое было раньше
(система ругается, но пытается загрузиться). Соответственно в генераторе
systemd сервисов для sysv-скриптов:

- зависимости с local-fs.target на соответствующие mounts вместо
  'requires' делаем 'wants'.
- добавляем в After local-fs.target

После чего убираем local-fs.target из basic.target вообще.

Итог:

- для SYSV скриптов ничего не изменится по сравнению с "до systemd"
  временем
- systemd сервисы будут запускаться только после монтирования необходимых
  им для работы каталогов

Соответственно недоступность очередного "/media/films" не будет
останавливать загрузку.

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

http://mithraen.ru/

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

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

[Alexey Shabalin]

5 августа 2014 г., 23:16 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> У нас сейчас с systemd есть проблема. Одна из тех, что вызывает массовое
> неприятие systemd у пользователей.
>
> Суть проблемы: при невозможности смонтировать любой из разделов
> упомянутый в /etc/fstab система останавливает загрузку, и далее уже
> требуются специальные знания для восстановления работоспособности системы.
>
> Причем проблема одинаково воспроизводится при невозможности смонтировать,
> к примеру /usr и какой-нибудь /home/user/films или /media/films.
>
> Предлагаю следующее решение и прошу комментариев.
>
> Зависимости на смонтированные FS
> ================================
>
> Сейчас монтирование *всех* разделов упомянутых в /etc/fstab происходит до
> собственно запуска большинства сервисов -- ибо они имеют зависимость на
> basic.target, который зависит от local-fs.target, которая зависит от
> монтирования всех разделов из /etc/fstab.
>
> В systemd есть встроенный метод делать зависимости конкретных сервисов на
> смонтированные FS: RequiresMountsFor.
>
> Для сервисов, которые имеют эту директиву в unit-файле зависимость на
> local-fs.target не требуется. Однако прописывать ее корректно всем
> мантейнерам было, есть и будет лень и некогда.
>
> Решения:
>
> 1. Нам никто не мешает сгенерировать её автоматически, еще на этапе сборки
> rpm-пакета: мы можем автоматически добавить в нее все каталоги,
> присутствующие в собираемом пакете.
>
> Насколько я понял, для этого нужно просто создать соответствующий
> /usr/lib/rpm/fixup-(something)?
>
> 2. Для SYSV скриптов предлагаю оставить то поведение, которое было раньше
> (система ругается, но пытается загрузиться). Соответственно в генераторе
> systemd сервисов для sysv-скриптов:
>
> - зависимости с local-fs.target на соответствующие mounts вместо
>   'requires' делаем 'wants'.
> - добавляем в After local-fs.target
>
> После чего убираем local-fs.target из basic.target вообще.
>
> Итог:
>
> - для SYSV скриптов ничего не изменится по сравнению с "до systemd"
>   временем
> - systemd сервисы будут запускаться только после монтирования необходимых
>   им для работы каталогов
>
> Соответственно недоступность очередного "/media/films" не будет
> останавливать загрузку.
>

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



-- 
Alexey Shabalin

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

[Денис Смирнов]

[-- 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 --]