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/