* [devel] systemd & проблемы с mount блокируют загрузку
@ 2014-08-05 19:16 Денис Смирнов
2014-08-06 16:47 ` Alexey Shabalin
0 siblings, 1 reply; 3+ messages in thread
From: Денис Смирнов @ 2014-08-05 19:16 UTC (permalink / raw)
To: devel
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [devel] systemd & проблемы с mount блокируют загрузку
2014-08-05 19:16 [devel] systemd & проблемы с mount блокируют загрузку Денис Смирнов
@ 2014-08-06 16:47 ` Alexey Shabalin
2014-08-06 21:46 ` Денис Смирнов
0 siblings, 1 reply; 3+ messages in thread
From: Alexey Shabalin @ 2014-08-06 16:47 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [devel] systemd & проблемы с mount блокируют загрузку
2014-08-06 16:47 ` Alexey Shabalin
@ 2014-08-06 21:46 ` Денис Смирнов
0 siblings, 0 replies; 3+ messages in thread
From: Денис Смирнов @ 2014-08-06 21:46 UTC (permalink / raw)
To: devel
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-08-06 21:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-05 19:16 [devel] systemd & проблемы с mount блокируют загрузку Денис Смирнов
2014-08-06 16:47 ` Alexey Shabalin
2014-08-06 21:46 ` Денис Смирнов
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git