После пяти месяцев разработки представлен релиз системного менеджера systemd 254. Наиболее заметным изменением в новой версии стала поддержка режима мягкой перезагрузки ("systemctl soft-reboot"), который приводит к перезапуску только компонентов пространства пользователя, не трогая ядро Linux. В новом режиме при перезагрузке не применяются стадии инициализации оборудования, вызова загрузчика, запуска и загрузки ядра, инициализации драйверов, загрузки прошивок и обработки initrd, что позволяет заметно ускорить перезапуск и уменьшить время простоя во время обновления окружений, использующих готовые системные образы...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59512
Кто сказал, что Оби Ван^W^W Солярис умер? Его дух и сила с нами!
Все катится в тартарары, ничего не работает, а-а-а-а-а.
А если во время этой "мягкой перезагрузки" вырубится электричество?
Я сказал что соплярис умер. Просто попробуй им воспользоваться на железе, моложе 10 лет.
И скорость на 86-й рахитектуре, и поддержка железа...
Но у нас есть OpenSolaris под названием illumos и дистрибутив его Ooenindiana.
Ну и чего там интересного относительно Linux?
> Добавлена настройка RootEphemeral, позволяющая использовать в сервисах, в которых
> выставлены параметры RootImage и RootDirectory, временные копии дискового образа
> или дерева каталогов, которые при запуске сервиса создаются через снапшоты btrfs
> и reflink-и btrfs/xfsО, круто, он теперь сам умеет _быстро_ фэйк-копию ОС делать. Сервисы получат что хотели, даже менять могут - но повредить основную ОС таки не смогут.
> Добавлена настройка MemoryKSM для выборочного включения в сервисах функции ядра,
> обеспечивающей слияние идентичных страниц памяти (KSM, Kernel Samepage Merging).Тоже здорово - можно дедупать RAM походим сервисам.
Что за нафиг, в 1 версии минимум 2 полезные мне фичи? Так держать.
> прекратить поддержку раздельных иерархий каталогов (когда /usr монтируется отдельно от корня или разделены каталоги /bin и /usr/bin, /lib и /usr/lib)кто-нибудь, остановите его
Останавливать надо было раньше. Еще первые выпуски нарушали файловую иерархию, иначе системда не заводилась.
Поздно фраер пить Боржоми, когда почки полетели.
Как раз на оборот, пусть больше колбасит, чем сильнее оторвётся тем больше народа придёт в классические дистрибутивы.
на винду?
мосье знает толк в извращениях.
Нет никаких "классических" дистрибутивов. Есть дистрибутивы которыми пользуется 1% линуксоидов. Но конечно же вместо "маргиналов" называют себя классическими юникс ветеранами ))
Ясно-понятно. Смузихлёбов тоже нет?
Если это тот самый 1% который пишет код то всё хорошо.
конечно, ибо показатель 99% биомассы - норма.
> Нет никаких "классических" дистрибутивов.А Windows? )
существуют люди которые добровольно пьют кокаколу,
мало того что пьют, так еще и платят за её деньги.вы конечно не поверите и будете смеяться, но я сам видел таких людей.
>> прекратить поддержку раздельных иерархий каталогов (когда /usr монтируется
>> отдельно от корня или разделены каталоги /bin и /usr/bin, /lib и /usr/lib)
> кто-нибудь, остановите егоСовременные дистры предпочитают переходить на "merged usr" - это когда все в /usr/* лежит а /bin, /sbin, /lib, ... - симлинки. Вообще система в 1 дире - удобнее, как по мне.
> система в 1 дире - удобнее, как по мнеСогласен. Ждём мержа /usr/bin и /usr/lib. Чтобы уж точно в одной дире. А то сейчас 10 мест и непонятно, где что лежит: хочешь библиотеку посмотреть - идёшь в /usr/lib, бинарник - в /usr/bin. Бардак, а не файловая система.
Ну давай, расскажи зачем тебе несколько бинарных директорий. Но только реальный юзкейс, а не жевание соплей.
Директории вообще не нужны, всё должно быть в /. cd(1) делаем симлинком на true(1), удаляем отовсюду из кода PATHы. Какая экономия кода и места! ^_^Расскажи зачем тебе директории. Тока рил юс кейз, а не жевание соплей.
У меня есть очень живой кейс. Моя система грузится в initrd, который я, кстати, могу генерить динамически, а /usr монтируется с диска.Иногда не монтируется, потому что нет драйверов для контроллера или ещё какой-нибудь железяки, на которой я гружу эту систему, но у меня всегда есть рабочий initrd с инструментами для рекавери, поиска дров, и так далее.
Система никогда не делает chroot, у неё корень всегда на initrd, и она продолжает работать даже если диск сдох.
То же самое можно сделать с /usr на NFS, когда "затравочный" образ запускается по сети, или с флешки на тонком клиенте.
А как решается вопрос с обновлением системы или установкой дополнительных пакетов если меняются файлы не только в /usr? А как сохраняются изменения в /etc?
Мое решение на базе LiveKit (Slax-like) - монтировать отдельно каждую директорию в '/' как overlayfs, а при изменении создавать squashfs бандлы из rw директорий overlayfs
> Мое решение на базе LiveKit (Slax-like) - монтировать отдельно каждую директорию в
> '/' как overlayfs, а при изменении создавать squashfs бандлы из rw
> директорий overlayfsСистемд с снапшотами/рефлинками забавнее сделал. Так программы с одной стороны как бы могут менять свое видение системы. И совместимость не страдает. С другой это никак не распостраняется на "parent" версию системы из которой это создано. А потом оно просто сносится. Такая вот транзиентная версия системы.
Если доразвить идею так можно отращивать хоть целое дерево ОС в разных состояниях из одного ридонли снапшота. И сносить их - по желанию. А переключить снапшот - в btrfs можно даже из grub, командлайном ядру, если уж по минимуму. При этом достаточно чтобы был жив grub, по большому счету, тогда можно будет отыграть на иной снапшот. Даже стирание кернела в /boot обыграть можно, однако :)
>> забавнее сделалВот именно что.
Система городилась для запуска и работы системы из флешек из ближайшего супермаркета.
Они просто сверхнадежно и свердолго работают в readonly режиме (внезапно да), да еще и быстро (потому что чтение происходит с уже сжатых образов (xz или zstd с блоком размером 1Мб))
и совершенно плохо работают (может потеряться целый раздел при обычном ребуте кнопкой системника) или внезапно дохнут в rw режиме (TLC имеет, насколько помню, только 1000 циклов перезаписи). А дефолтно настроенная работающая система любит обязательно что-то писать + btrfs имеет неразумный write amplification>> Если доразвить идею так можно отращивать хоть целое дерево ОС
Так доразвивать ничего вроде и не надо. Это и была изначальная задумка, как еще одна реализация docker-подобных технологий.
Там просто, чтобы это взлетело, еще ненаписан модуль systemd-backupd, надо только подождать. В следующих версиях Fedora будем весело это испытывать и готовить технологию для Enterprize. К счастью, когда дипломная работа потеряется где-то на одной из веток дерева снапшотов, rhbm получит мотивированного написателя багрепорта (правда багрепортописатель все равно не получит свой файл диплома, но зато хоть какая-то отрада для души будет).>> Даже стирание кернела в /boot обыграть можно, однако
Это прикольно? Или зачем так делать?
> Они просто сверхнадежно и свердолго работают в readonly режиме (внезапно да), да
> еще и быстро (потому что чтение происходит с уже сжатых образов
> (xz или zstd с блоком размером 1Мб))Я на такие btrfs с схемой dup (2 копии блоков на 1 девайсе) кладу. Емкость ополовинивается, зато утечку заряда переживает, а чексуммы позволяют понимать насколько этому пора в мусор - ДО того как развалится. Можно и readonly делать. А можно и read-write. Один флаг на снапшот сменить. Удобно. Поставил апдейты и сделал readonly опять.
Если надо, из оригинала снапшота можно отрастить целое дерево альтернативных вариантов развития системы. Записываемых, или не очень. Сабж к этому и пришел.
> и совершенно плохо работают (может потеряться целый раздел при обычном ребуте кнопкой
> системника) или внезапно дохнут в rw режиме (TLC имеет, насколько помню,Это если партишн класть в тот же eraseblock что активно ворочаемую файлуху. Лечится отступом от начала девайса на 32-64 мега, чтобы блок с партишном контроллер не трогал при записях. Смотрите как фабричные ФС сделаны до того как сносить, увидите.
> только 1000 циклов перезаписи). А дефолтно настроенная работающая система любит обязательно
> что-то писать + btrfs имеет неразумный write amplification1. Какой write amplification в readonly варианте?! :)
2. Если надо апдейты накатить, можно временно снять ридонли и порулить как обычно, а не вон те танцы.
3. CoW удобен для хренового FTL в таких флешках - даже если он лажанет, CoW размазывает записи по площади сам, он не протирает одни и те же блоки.> Так доразвивать ничего вроде и не надо. Это и была изначальная задумка,
> как еще одна реализация docker-подобных технологий.Докер не про это как таковой. Это ни о чем без эффективного backing storage способного на такую семантику. Без этого операция будет медленной и дорогой, по поводу чего и не использовалось особо. Вы же не будете "честно" копировать инсталл ОС при каждом запуске сервиса и стирать потом? Докер сам по себе с этим ничего не сделает, без CoW очень дорогая операция выходит.
> Там просто, чтобы это взлетело, еще ненаписан модуль systemd-backupd, надо только подождать.
Снапшоты - не бэкапы: всего 1 бэд и вся пачка снапшотов ссылающихся на это место в ауте.
> В следующих версиях Fedora будем весело это испытывать и готовить технологию
> для Enterprize.Это вы там сами как-нибудь.
> багрепортописатель все равно не получит свой файл диплома, но зато хоть
> какая-то отрада для души будет).У меня данные не теряются, тьфу-тьфу. Я их даже другим восстанавливаю иногда.
>>> Даже стирание кернела в /boot обыграть можно, однако
> Это прикольно? Или зачем так делать?Позволяет откатить откровенно фатальную в более примитивных конфигах ситуацию - менеджмент ОС "почти как на виртуалке". В том числе и по возможности передумать и вернуть как было. Мне пригодилось когда в новом снапшоте кернел как оказалось расстыковался с модулями. Кернел при этом был, но радости, если у него модули отавалились? Он даже блочный девайс зацепить не мог и это почти как вон то. Но можно прямо из GRUB зацепить снапшот в котором ЭТОГО еще не было, читанув его initrd и kernel и (если надо) уточнив кернелу что мы хотим как рутфс именно этот снапшот.
Спасибо за первые ответы. Ценны>> без эффективного backing storage
на > как еще одна реализация docker-подобных технологий.
ну вот в systemd c btrfs более эффективная реализация с дедупликацией на уровне блоков устройства, а не на уровне файлов с overlayfs (aufs).
>> Докер не про это как таковой.Doker, Flatpack, Snap все про это имеют
>> Снапшоты - не бэкапы: всего 1 бэд и вся пачка снапшотов ссылающихся на это место в ауте.
Именно.
Но будем последовательны, зачем бекапить снепшоты какими-то левыми тузлами от Васяна (или использовать существующие системы бекапа файлов на docker-like системах), если правильно дождаться православного systemd-backupd. Ну в самом деле, не использовать же системы с медленной и дорогой семантикой и неэффективными backing storage>> Позволяет откатить откровенно ... именно этот снапшот
Оно то конечно имеет право на жизнь и может со временем это войдет в "хорошие практики", но по моему в этом нет ортогональности: обычно "удаляем добавляем редактируем файлы" или "удаляем ставим через пакетный менеджер", а тут вдруг раз: и снепшотами это дело, снепшотами
> Спасибо за первые ответы. ЦенныEnjoy.
> на как еще одна реализация docker-подобных технологий.
Это было задолго до докеров. Виртуализаторы умеют CoW-диски с снапшотами лет 20+ минимум. Линукс умеет RCU для процессов еще больше, идея та же но для RAM: (10 x процесс) не жрет (10x RAM). Жрет "core set" + (10 x delta). Это настолько часть Linux, что clone() и unshare() целиком про это, а fork() их частный случай. Unshared меньше - "тред". Больше - "контейнер". Все сводится к "дельте" с приватными ресурсами.
Это древние технологии и концепции. Их эффективное пилотирование требует понимания концепции. Тогда все круто, просто и эффективно.
> ну вот в systemd c btrfs более эффективная реализация с дедупликацией на
> уровне блоков устройства, а не на уровне файлов с overlayfs (aufs).Скорее "на уровне экстентов". Будет лишь 2-й набор указателей на те же блоки. "Копия" рефлинком или снапшотом сводится к развесовке набора указателей, быстро и занимает лишь немного места в метаданных. А если состояние расходится, указатели измененной части апдейтятся показывать на новый вариант.
Бонусом это как семантика полного журнала. Если запись срубилась, указатели не успели отапдейтить, "rollback" сам получается а fsck при этом не требуется. Поэтому все и возятся с CoW. Даже если за это и отливается - нуждой в GC, бесконечные "дельты" съедят все место.
> Doker, Flatpack, Snap все про это имеют
Эффективно ТАК можно только если уровнем ниже живет технология которая в такую семантику операций умеет. На каком-нибудь EXT4 вы ЭТО нормально не сможете. Будет либо полное копирование (для всей системы - медленно), либо дурной набор костылей и подпорок, мучительный в управлении и контринтуитивный.
> Но будем последовательны, зачем бекапить снепшоты какими-то левыми тузлами от Васяна
Я не бэкаплю снапшоты левыми тулзами от Васяна. Ключевые точки жизни систем интересных мне я получше васянов знаю.
> если правильно дождаться православного systemd-backupd.
Системные задачи есть здесь и сейчас. Когда и если будут другие решения я подумаю надо ли оно мне в том виде. Скажем я не пользуюсь -networkd и -timesyncd, вплоть до неустановки пакетов.
> Ну в самом деле, не использовать же системы с медленной и дорогой
> семантикой и неэффективными backing storageЯ не живу вечно, чтобы тратить на отношения с системной рутиной в разы больше времени - когда уже можно в разы меньше.
> Оно то конечно имеет право на жизнь и может со временем это
> войдет в "хорошие практики", но по моему в этом нет ортогональности:Если мы про ортогональность, мне ортогонально что и кто пишет в практики и проч. Я "решаю задачу" и у меня своя голова на плечах при этом, в процессе я могу создать не существовавшую ранее технологию или их комбинацию.
> обычно "удаляем добавляем редактируем файлы" или "удаляем ставим через пакетный менеджер",
> а тут вдруг раз: и снепшотами это дело, снепшотамиЕсли уже есть звездолет с машиной времени способный путешествовать в пространстве-времени произвольно, странно пилотировать его как привычный кукурузник. Это неэффективно.
Ну, что ж, опрыскиваем поля и дальше на кукурузниках. Пробовали звездолет, ракетной струей нафиг поле сожгли. Пока, с опаской, но и с интересом, поглядываем в сторонке
> Ну, что ж, опрыскиваем поля и дальше на кукурузниках. Пробовали звездолет, ракетной
> струей нафиг поле сожгли. Пока, с опаской, но и с интересом,
> поглядываем в сторонкеА если дикаря в кукурузник посадить, он и сам угробится и поле сожжот. Так что дать ему ручную брызгалку. Да и вообще, его предки без химикатов обходились. Но почему-то желающих заниматься сельским хозяйством в таком виде - все меньше. Так и тут. И да, я не испытываю проблем подрихтовать технологии под именно мои нужды. Если надо чтобы звездолет висел над полем и не портил его - окей, конструкция будет несколько модифицирована и следующая версия так сможет.
> У меня есть очень живой кейс. Моя система грузится в initrd, который
> я, кстати, могу генерить динамически, а /usr монтируется с диска.С таким же успехом можно генерить initrd динамически и с "merged usr". Большая часть дистров так и делает сто лет: на автомате хуком после инсталла кернела в пакетнике генерят ему в пару initrd с ТЕМИ модулями ядра. Так что ваш "хайтек" давно уже "попсовый ширпотреб", так даже убунта умеет. А основная система монтируется... да в общем откуда угодно, к initrd это мало отношения имеет в общем случае. По нормальному они декорелированы и пересекаются только тем фактом что модули и некоторые программы (e.g. busybox) в initrd взяты из вон того ядра.
> Иногда не монтируется, потому что нет драйверов для контроллера или ещё какой-нибудь
> железяки, на которой я гружу эту систему, но у меня всегда
> есть рабочий initrd с инструментами для рекавери, поиска дров, и так далее.Основную систему вообще не обязано интересовать что там в initrd, а initrd в принципе может запустить что угодно, структурированное как угодно. Соответственно никаких минусов у вон того решения - нет. Для инитрд вообще есть механизм pivot root - можно весь рутфс свичнуть. И кстати ничему не противоречит если initrd будет тоже "merged usr" по структуре.
И более того - завязка initrd на структуру системы, или системы на структуру initrd делает это хрупким и кривым решением.
> Система никогда не делает chroot, у неё корень всегда на initrd, и
> она продолжает работать даже если диск сдох.Если диск сдох, initrd с него тоже не прочитается? А если initrd все же читается - ну ок, с нем и будем тусоваться. И _его_ тулсах. Ведь уповать на систему на дохлом диске в рекавери не было частью плана, так? :) Да и не понятно что вы делать намерены в инитрд если "диск сдох".
> То же самое можно сделать с /usr на NFS, когда "затравочный" образ
> запускается по сети, или с флешки на тонком клиенте.В линукс есть множество вариантов как и что делать, "merged usr" уж точно не делает подобные вещи "нерешаемыми".
Тут базисная идея, вокруг которой все крутится: не делать pivot_root.
Вторая базисная идея, "жирный" initrd с рекавери инструментами.
>> завязка initrd на структуру системы, или системы на структуру initrd делает это хрупким и кривым решением
>> хрупкимВся эта система как раз и городится для того, чтобы избавиться от "хрупкости" современных решений (гарантированно есть рекавери без перезагрузки)
>> кривым решением
Ну не знаю, как только научился писать скрипты, сразу пришла мысль "А так можно было?". Вот при постройке мышления через призму systemd, конечно такой мысли не будет. Будем ждать очередную опцию в systemd и радоваться как rhbm развивает IT и двигает нас в светлое будущее
>> "merged usr" уж точно не делает подобные вещи "нерешаемыми"
но, по крайней мере делает их сложней. Мейнтейнеры перестанут следить чтобы init (а может и getty, polkit и проч) не имел например свои разделяемые библиотеки на /usr (в итоге посыпавшийся хард тянет в бездну вместе с собой и init-ы с polkit-ами в придачу и нетуту у нася рекавери).
Оно то конечно можно нанять девопса, накупить оборудования, обмазаться RAID-ами, btrfs-ами со снапшотами, docker-ами (а может и k8s надо) и получить стройную и изящную систему с нереально малым временем восттановления после сбоев , а можно сделать непоправимое, недопустимое и осуждаемое - написать три шелл-скрипта по сотне (о боже!) строк, и получить (для специалиста некоего уровня квалификации) время восстановления, ну к примеру, приблизительно от десяти минут до нескольких часов (ну разобраться что-там и при необходимости нагуглить
> Тут базисная идея, вокруг которой все крутится: не делать pivot_root.Не понимаю чего б не пользоваться фичами ОС.
> Вторая базисная идея, "жирный" initrd с рекавери инструментами.
Дебиан и убунта так сто лет умеют. Генеря ЭТО на автомате. И очень кстати что он минимально зависит от основной ОС. Меньше точек для развала.
Но вообще откат на работающий снапшот быстрей танцев с системой, с тем же эффектом. И гарантированнее по эффекту, почти как снапшот VM.
> "хрупкости" современных решений (гарантированно есть рекавери без перезагрузки)
На мой вкус, у вас получилось больше точек где что-то может пойти не так и сложновато.
> сразу пришла мысль "А так можно было?".
В линукс можно делать много странных вещей. Этим он и крут. Но ниоткуда не следует что нечто достижимо 1 способом и/или что энный способ - наилучший. Вот и merged usr реально не мешает.
> Вот при постройке мышления через призму systemd
Я рулил системами до системд. И имел возможность сравнить подходы. Системд упростил многие вещи и сделал их удобнее.
> Будем ждать очередную опцию в systemd и
> радоваться как rhbm развивает IT и двигает нас в светлое будущееЯ не обломаюсь и сам сделать сравнимое - но лучше если не придется изобретать вел i++'й раз. Копирование системы в чрут очень древний спорт. А это мастеркласс как надо было.
> но, по крайней мере делает их сложней.
Вместо 4 критичных дир по сути 1 - "сложней"? Да ладно?
> Мейнтейнеры перестанут следить чтобы init (а может и getty, polkit и проч) не имел
> например свои разделяемые библиотеки на /usrА какая разница, связи с либами в /usr или где-то еще. Разваливаются либы совершенно одинаково, плюс-минус. А если бэд под системной либой это вообще упс. Если это не btrfs с схемой DUP или RAID'ом, там-то починится.
> (в итоге посыпавшийся хард тянет в бездну вместе с собой и init-ы с polkit-ами
> в придачу и нетуту у нася рекавери).Не понимаю откуда следует что с посыпавшегося харда ядро и инитрд прочтутся. И чем жирнее инитрд, тем вероятнее что он испытает проблемы чтения. В этом смысле btrfs с схемой DUP мне нравится, возьмет нужный блок из 2 копии и дело с концом. Еще и починит порушеное, винч как раз сможет при случае ремапнуть бэд. Вообще "without human supervision" - я это изначально для добавлени жизни автоматике где некому чинить систему затевал, но зашло и теперь так и некоторые иные вещи сделаны.
> Оно то конечно можно нанять девопса, накупить оборудования, обмазаться RAID-ами, btrfs-ами
> со снапшотами, docker-ами (а может и k8s надо)Не вижу проблем нарулить снапшоты btrfs в 1 лицо.
> квалификации) время восстановления, ну к примеру, приблизительно от десяти минут до
> нескольких часов (ну разобраться что-там и при необходимости нагуглитьЕще лучше если их писать не придется :). Ну вот как в сабже, с его transient'ными снапшотами-для-сервисов. Конечно можно это и самому было скриптом сделать. И даже пнуть скрипты делающие это как ExecStartPre= и ExecStopPost= юнита системды, спихнув проблему детектирования запуска и останова программы на системд, он by design в курсе. Но вон то еще проще.
И время починки систем лучше не "часы" а "пара минут" - с снапшотами вообще не вопрос.
>Не понимаю чего б не пользоваться фичами ОС.Вы гений просто. Если система будет включать штатную кастрацию юзера, вы тоже ей будете пользоваться "потому что есть штатная функция"?
>Но вообще откат на работающий снапшот быстрей танцев с системой, с тем же эффектом.
Как вы этот снапшот будете восстанавливать, если у вас система не грузится? Нужен минимальный initrd, чтобы запустить ту команду, которая этот снапшот восстанавливает.
>На мой вкус, у вас получилось больше точек где что-то может пойти не так и сложновато.
Я потратил овердофига рабочего времени в прошлом году, чтобы понять, что там за такой невероятно важный сервис в centos, plymouth, что система готова ждать его вечно, и без него не загрузится. А потом оказалось, что это, ****, картиночка закрывающая логи.
Но нет, у меня есть точка, из которой я могу всю эту идиотию отладить.
>Не понимаю откуда следует что с посыпавшегося харда ядро и инитрд прочтутся.
Потому что это другая партиция! Если у вас развалилась ФС на /usr, вам нужно откуда-то запустить ddrescue, или fsck. Или вообще этот initrd можно загрузить по сети. (Нет, таскать 400 гигабайт /usr/ по сети я не согласен.) Больше того, initrd вообще грузится не ядром, а grub, поэтому шансов на то, что он не загрузится, намного меньше.
>>И время починки систем лучше не "часы" а "пара минут" - с снапшотами вообще не вопрос.
Никаких снапшотов по-умолчанию нет. Даже если вы настоили снапшоты по крону, всё равно это требует какой-то лютой самоорганизации, чтобы проверить, что они и правда делаются. Никакие снапшоты не взлетают нигде, кроме какого-нибудь лютого devops, где делать снапшоты -- это чья-то должностная обязанность. У нормального юзера ещё и места для снапшотов нет с вероятностью 100%. Даже в Windows, где юзера ограничивают во всём, что можно, "Точки отката" почти никогда не спасают ни от чего.
>В линукс есть множество вариантов как и что делать, "merged usr" уж точно не делает подобные вещи "нерешаемыми".
В линукс можно самому себе размёрджить usr, если хочется. Вопрос в затраченных усилиях.
> Вы гений просто. Если система будет включать штатную кастрацию юзера, вы тоже
> ей будете пользоваться "потому что есть штатная функция"?Некоторым я б подогнал систему с такой фичой, было бы круто. А от pivot root минусов я никаких не вижу.
> Как вы этот снапшот будете восстанавливать, если у вас система не грузится?
Попрошу GRUB прочитать ядро и инитрд из _работающего_ снапшота. И рутфсом укажу его же. Опа, ловкость рук и возврат в снапшот системы за пару минут - без утилит вообще.
> Нужен минимальный initrd, чтобы запустить ту команду, которая этот снапшот восстанавливает.
Это мультивселенная. И загрузка в ту ее версию где все было ОК. Система существовала. Работала. Так просто и банально. В этом прелесть снапшотов - рекавери как таковой нет. Даже, вот, команды может не быть. Потом, когда взлетит, конечно, имеет смысл сделать этот снапшот (или его клон, если хочется сохранить как шаблон) дефолтным, чтобы оно сразу в ЭТО стартовало.
Это с btrfs, он спокойно шарится по subvolumes и потому доступается к снапшотам. Может и с zfs что-то такое можно, не смотрел можно ли grub убедить снапшот читануть и как это.
> Я потратил овердофига рабочего времени в прошлом году, чтобы понять, что там
> за такой невероятно важный сервис в centos, plymouth,Потратить овердофига времени на изучение загрузочной заставки - сэр жжот напалмом. Но при чем тут системд или вообще ОСи?
> Но нет, у меня есть точка, из которой я могу всю эту идиотию отладить.
В системде вообще есть встроенные средства для такого. И systemd-analyze blame для поиска тех кто медленно грущится. Удачи так с шелскриптами, чтоб 1 командой такие данные то, без танцев. И ничего сравнимого с systemclt -a в sysv нет.
>>Не понимаю откуда следует что с посыпавшегося харда ядро и инитрд прочтутся.
> Потому что это другая партиция!Вот еще мне не хватало лоскутные одеяла устраивать.
> Если у вас развалилась ФС на /usr, вам нужно откуда-то запустить ddrescue, или fsck.
Если у меня крутой развал - и это рекавери, я видите ли, прицеплю к другому компу и там разверну полноценное действо. Где могу что угодно, вплоть до мануального ресета воон того контроллера если винч или контроллер задумались на полчаса. Или бутявку прицеплю и в нормальном гуйном окружении с приличной терминалкой и солидным набором софта, типа whdd и проц. А заниматься таким из init - это типа сбора кораблика в бутылке, для эстетов. Очень неэффективно по времени.
> Или вообще этот initrd можно загрузить по сети. (Нет, таскать 400 гигабайт /usr/ по сети
> я не согласен.)А в чем прикол грузить initrd по сети, а usr - нет? Впрочем я не понимаю что мешает так делать при "merged usr". Где и в чем наступит разница? Конкретизируйте.
> Больше того, initrd вообще грузится не ядром, а
> grub, поэтому шансов на то, что он не загрузится, намного меньше.Так я и не спорил с этим. А при чем тут merged usr? Initrd может быть прекрасно сгенерен и из него. Вполне норм. размера, болшая часть - модули ядра. Современные генераторы initrd очень выборочно в него файло добавляют и это настраиваемо. Весь usr они в него не будут класть.
> Никаких снапшотов по-умолчанию нет.
Электричества на планете тоже по умолчанию не было. И компов. И?
> Даже если вы настоили снапшоты по крону, всё равно это требует какой-то
> лютой самоорганизации, чтобы проверить, что они и правда делаются.Требует всего пары вещей.
1) Привести систему в более-менее желаемое состояние.
2) Заснапшотить в "ключевой точке пространства-времени".Ну ок, изредка можно переделывать снапшот, чтобы меньше переигрывать. Я без крона свои ключевые точки знаю. Как правило после крупных подтяжек версий. И перед большими апгрейдами в исходе которых не уверен.
> Никакие снапшоты не взлетают нигде, кроме какого-нибудь лютого devops,
Я не девопс но тоже ценю продвинутые технологии экономящие время. Это делает меня мощнее.
> где делать снапшоты -- это чья-то должностная обязанность.
Набрать пару команд - прямо капец "должность". Вы больше с своими штуками танцуете имхо.
> У нормального юзера ещё и места для снапшотов нет с вероятностью 100%.
В нормальных технологиях (CoW, что в VM, что в ФС) место занимает только дельта. Если поставили пару апдейтов - место займут только пару апдейтов. А так это 2 ссылки на одни и те же блоки в основном. Потому и не аналог бэкапов: бэд вынесет ВСЕ что на него ссылалось.
Поскольку stable дистры в пределах релиза не очень меняются, вон то не особая проблема при нормальной эксплуатации.
> Даже в Windows
Там все это сделано архаично, тормозно, криво и хреново. Это этажерка братьев райт, а у меня звездолет умеющий в гиперпространство уже.
> В линукс можно самому себе размёрджить usr, если хочется. Вопрос в затраченных усилиях.
Так эти усилия тратит генератор initrd а не я, ему похрен, он железный :)
Я тут недавно читал так популярную сейчас фантастическую постапокалиптику. Так вот что там пишут:
Главный герой (гражданский Жень) сидит в бункере (гражданском Жень) или самовыкопанном блиндаже (Жень) вместе с соседями. Этот чувак работает на удаленке и отлаживает систему промавтоматики (гражданскую Жень). Он разбирается в бузибокс, но слабо в systemd (как то этих платках что-то не дошло еще). Электричество отключилось два часа назад. Час назад перестал пищать UPS (тоже сел), но еще осталось два часа работы от встроенной батареи ноутбука. Обычно перерывов в электроснабжении больше одного дня не бывает. Только раз было два дня. Бензогенератора нет.
После обновления CentOS Steam и требующейся перезагрузки он обнаруживает, что система не грузится (остановка на каком-то процессе plumount). Он перезагружается в предыдущий btrfs snapshot обновляет систему и понимает, что попал в зацикленное время (день сурка): остановка на каком-то процессе plumount.
Тут главный герой выходит из гражданского блиндажа (там не было указано почему он туда залазил и вдруг почему-то решил что от туда можно вылазить) и понимает, что необходимо разработать систему, которая могла бы на живую дебажить загрузку "ентерпрайз" систем. Это позволило бы использовать время в блиндаже с большей пользой. Для обмена опыта он идет на сайт хакеров, где ему советуют:
>> я видите ли, прицеплю к другому компу и там разверну полноценное действо.а он понимает, что при проблемах у него не будет другого устройства, зато будут дополнительные флешки с необходимым софтом и данными.
После этого он просветляется, танцует и живет счастливо
Изначально постановка вопроса у меня: "хотим решить задачу". Далее вопрос какие средства доступны. И я ранжирую доступные варианты, выбирая тот который предположительно самый быстрый и вероятный по успеху.Но вообще...
1) Финт с вгрузкой снапшота прямо GRUB очень в духе. Его даже утилитой называть неудобно.
2) DUP как схема хранения на ноуте разок парировала 1 случайный бэд. И вместо развала ОС и ФС - "csum failed .... corrected".Законами природы можно пользоваться для себя. Есть разница, проигрываем мы если бэд попал под критичные файлы или метаданные - VS - "бэды должны накрыть 2 физически разных региона хранящих блоки по вон тому логическому смещению". Я попробовал и так теорвер намного интереснее. Нет, он не проигрывает даже на откровенно сыпучей флехе за обозримое время.
Кстати, на хабре есть интересный квест. Что если мы остались с AVR'кой и кучкой хлама на необитаемом острове?! Без компов и ноутов. А нащелкаем-ка программу в нее вообще без компов! Видите, даже и ноута не надо. И ассемблировать можно на листочке. Но в более реалистичных ситуациях это очень неэффективно по времени.
...а еще нормальный инженер найдет пару десятков способов добычи электричества с минимальными допущениями. Даже если я ОС на ноуте починю, но батарейки на 2 часа осталось - круто, а через 2 часа чего делать?
>> ...а еще нормальный инженер найдет пару десятков способов добычи электричества с минимальными допущениямивобще-то главный герой является электриком по основной специальности. И бензинового генератора нет по причине демаскировки от его работы. Прийдет ночью в масках банда бывших сидельцев, по совместительству гомосексуалистов, с другого края селения, и отожмет эти ваши тарахтящие способы добычи электричества.
Фантастика, там только для того, чтобы не потерли за политический оффтоп
> банда бывших сидельцев, по совместительству гомосексуалистов, с другого края селения,При намеке на такие расклады я имхо предприму определенные меры
1) Если ожидаются такие условия, логично решать задачу с учетом ограничений "не должно шуметь" и "должно быть незаметным". На бензиновых генераторах мир не заканчивается. А ноуту много не надо.2) Если ожидаются плохие люди, локацию можно подготовить к теплой встрече, в формате который надолго отобьет охоту. Я знаю интересные способы, которые заставят пару поколений суеверно обходить "проклятое место".
> и отожмет эти ваши тарахтящие способы добычи электричества.
Есть странные легенды о проклятых местах, куда лучше не соваться. Мне эти легенды нравятся. И я знаю как создавать такие места. Если вопрос встанет так, и законы не будут мешать, я оттянусь по полной имхо.
> Фантастика, там только для того, чтобы не потерли за политический оффтоп
А мне нравится sci-fi, там часто показывают самые странные ситуации и выход из них. Что еще интереснее, 80% этого не такая уж и фантастика...
>> Я знаю интересные способы,ну вот, если прямо сейчас открыть новости, то можно увидеть, что недалекие люди от отчаяния:
здесь пришел с гранатой в пенсионный фонд
у вас пришел с гранатой на автозаправку>> Мне эти легенды нравятся. ... суеверно обходить "проклятое место"
Мне тоже они офигенно нравились пока не понадобилось. И тут жестокая встреча с реальностью: в критической ситуации ты не подымаешься до уровня своих ожиданий, а опускаешься до уровня своей тренированности. В том числе и в технологиях
И вот если повышать уровень тренировнности, то
>> и законы не будут мешатьдаже в беззаконии будут законы. Сплошного беспредела не будет (даже с бандитами).
А вот такому тренирующемуся сразу найдут чем заняться. Выдадут броню 5-го класса, например.
Нинзями ж не рождаемся
> у вас пришел с гранатой на автозаправкуЕсли хрыч перепутает будку с генератором в подготовленной локации, имхо, граната ему может пригодиться.
> с реальностью: в критической ситуации ты не подымаешься до уровня своих
> ожиданий, а опускаешься до уровня своей тренированности. В том числе и в технологияхНормальному инженеру много и не надо, надо креативное мышление, да поработать на результат. Чтобы испортить несколько двуногих неожиданными для них и страшными для окруюающих способами, супер технологий не требуется. А человечество всяко оставит достаточно артефактов после себя для имплементации этих идей.
> даже в беззаконии будут законы. Сплошного беспредела не будет (даже с бандитами).
А гиблое место это гиблое место. После 1-2 убедительных примеров остальным врядли захочется туда соваться.
> А вот такому тренирующемуся сразу найдут чем заняться. Выдадут броню 5-го класса,
> например. Нинзями ж не рождаемсяБроня 5 класса не спасает от довольно большого числа интересных факторов с которыми можно познакомиться в этом мире. Особенно если вас ждали.
Надо соместить несовместимое
SOHO оборудование впихнуть в гражданский military-like environment
> Никаких снапшотов по-умолчанию нет.В NixOS эта проблема решена. И, кстати, с /usr тоже - там в нём лежит только /usr/bin/env, всё остальное - в /nix/store/.
> Согласен. Ждём мержа /usr/bin и /usr/lib. Чтобы уж точно в одной дире.А зачем? Оно и так в 1 дире теперь - /usr.
> А то сейчас 10 мест и непонятно, где что лежит: хочешь
> библиотеку посмотреть - идёшь в /usr/lib, бинарник - в /usr/bin. Бардак,
> а не файловая система.Бардак - это когда есть функцинально дублирующиеся /bin и /usr/bin, /lib и /usr/lib, и так далее. В этом не было никакого смысла - кроме того что давным давно кому-то из создателей *nix не хватило места на диске и они вынесли часть системы в /usr. А когда полсистемы там, а полсистемы тут, по хзкакому принципу - очень так себе.
А разделение на главный/полуглавный? У общества без цветовой дифференцыацыи штанов нет цели.
> А разделение на главный/полуглавный? У общества без цветовой дифференцыацыи штанов нет цели.Это какой-то не технический аргумент. Впрочем у меня намного более сложная структура в целом. Если я снесу эту виртуалку, не такая уж это и проблема. Новую раскатаю из шаблона. Я использую современные технологии если они позволяют рулить проще и быстрее.
>> по хзкакому принципу - очень так себеman hier
А вообще, хорошо бы иметь сильную руку, которая бы императивно насадила идеи GoboLinux в массы.
Это сразу бы, раз в 10 увеличило число людей понимающих, где в Линукс что лежит:
/bin, /sbin, /lib -> /windows (или более либерально в /linux)
/usr/* -> /Program Files
/var/* -> /Program Data
/home/* -> /Users
> man hierТам нет хорошего rationale. И как по мне сбагрить в 1 диру нормально как раз.
А на винды кивать не надо - они наверное раз пять или больше иерархию у себя переделывали, да еще симлинки для совместимости и подвиртуализовывание вида ФС для программ практикуют, смотря 32 она или 64 бита. Получается очень неинтуитивно, криво и много мусора для совместимости с старым бинарным легаси не знающим что дира переехала.
Вот в /linux вместо /usr было бы логичнее. Но это сильно переделывать софт придется.
>> Там нет хорошего rationaleТам и не будет. Для ваших кейсов действительно лучше смержить все в /usr. Ну и вы же понимаете, что мерж в /usr, а не подьем в '/' вызван вот именно этим:
>> Но это сильно переделывать софт придется.Ну для моих кейсов дробление есть благо - больше явной семантики, которую кто-то уже указал (криво правда указал, но что уж тут поделать)
А изначальная семантика вообще была: хард маленький, невлазит, вынесем невмещающееся на другой хард и примонтируем в /usr
Думаю, вы тут потеряли то, что есть вообще концепция дробления, как таковая. И эта концепция позволяет например размещать ветки дерева на разных блочных, сетевых устройствах и назначать им разные свойства (ro, noexec и проч)
Просто эта концепция дробления определяется консенсусом мейнтейнеров или указкой сверху
и она движется в сторону мержа (что для вас хорошо, а для меня плохо)>> А на винды кивать не надо
Надо. Виндовую семантику понимает намного большее количество пользователей.
Основного бардака они не видят, потому что системные файлы по умолчанию не отображаются
Для остального бардака уже выработана "выборочная слепота", как на рекламу на сайтах.
> Там и не будет. Для ваших кейсов действительно лучше смержить все в /usr.Я не вижу кейсы которые "merged usr" как-то непреодолимо нагибает.
> Ну и вы же понимаете, что мерж в /usr, а не подьем в '/' вызван вот именно этим:
>>> Но это сильно переделывать софт придется.Типа того, компромисс - и система в 1 дире, и compat не порушен. Достижение цели простым и быстрым способом. Чуть менее элегантно, но работает.
> Ну для моих кейсов дробление есть благо
Насколько я помню, есть идея не умножать сущности без необходимости. Мне эта идея нравится. Ни к чему хорошему зоопарк сущностей не приводит, только нагрузка по менеджменту/майнтенансу добавляется.
> Думаю, вы тут потеряли то, что есть вообще концепция дробления, как таковая.
> И эта концепция позволяет например размещать ветки дерева на разных блочных,
> сетевых устройствах и назначать им разные свойства (ro, noexec и проч)Самое интересное что "merged usr" никак этому всему не мешает, если это зачем-то надо. Ну и системд опять же может достичь сравнимого эффекта, и намного больше, скажем показывая сервису весьма кастомный view системы, с не менее кастомными правами, как раз монтируя из кусков новый view. А вон тот снапшот - вы даже можете расхакать в хлам. Но там будет только система и данные сервиса. При шатдауне сервиса хаксор в нем будет аннулирован вместе с снапшотом. Он гадил в параллельной вселенной, никак не затрагивает остальные варианты развития событий.
> Просто эта концепция дробления определяется консенсусом мейнтейнеров или указкой сверху
> и она движется в сторону мержа (что для вас хорошо, а для меня плохо)В линухе сложно что-то жестко навязать. И никто мне ничего не навязывает, я сам предпочитаю эффективный менеджмент моих систем с уменьшением нагрузки на меня. У меня довольно много систем развелось и если я буду каждую окучивать по 2 часа постоянно, я так далеко не уеду.
>>> А на винды кивать не надо
> Надо. Виндовую семантику понимает намного большее количество пользователей.И почему это меня должно волновать? Я с виндов ушел ...цать лет назад и забыл их как страшный сон. Я не против чтобы взять те идеи которые хорошо работали, а с грузом легаси, хреновыи идеями и легаси мс пусть сам и мыкается.
> Основного бардака они не видят, потому что системные файлы по умолчанию не отображаются
Если кто замел мусор под коврик это не значит что его нет. И более того - это становится проблемой когда системой хочется более продвинуто порулить.
> Для остального бардака уже выработана "выборочная слепота", как на рекламу на сайтах.
Если 3 диры -> 1 это как раз "уменьшение бардака" :). А для рекламы на сайтах я выработал жесткие адблокер и вебфайрвол, так что оно и пикнуть через них не смеет.
>> Не, ну это же классика кун-фу:
>> Сначала ты не знаешь, что нельзя делать то-то
>> Потом знаешь, что нельзя делать то-то
>> Потом ты понимаешь, что иногда таки можно делать то-то
>> Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться >> желаемого, и все из них практически равноправны.
>> Когда тебя спрашивают "как мне добиться желаемого", ты быстро перебираешь в уме эти шестьдесять >> шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: "вообще-то, главное >> — гармония."
>> На вопрос обиженных учеников: "а как ее добиться?", ты говоришь: "никогда не делайте то-то".
>>> На вопрос обиженных учеников: "а как ее добиться?", ты говоришь: "никогда не делайте то-то".Чтобы метить в учителя надо знать больше учеников, имхо. А в линухе обычно есть более 1 способа сделать что хотелось. Для лично меня 1 дира гармоничнее 3 ибо не стоит умножать сущности без необходимости. И я не вижу где наступает именно "необходимость". Вкусовщина - еще может быть.
Всё верно делает, этот бардак сто лет никому не нужен.
> Для сборки systemd теперь необходим инструментарий Meson как минимум версии 0.60.0.А были бы autotools, мы бы никогда не читали, что нужна новая версия bash, dash, ksh, или иного sh.
ага, autoconf version 2.13 required, помню-помню
Ты неправильно помнишь.
Ага, было такое) Для меня вообще открытие, что кому-то нравятся автотулзы)
Ну мне нравятся автотулзы. Эпичный набор костылей, но, зараза, ценен тем, что можно очень легко поправить, если где-то в самих автотулзах шляпа вылезла.
>> Для сборки systemd теперь необходим инструментарий Meson как минимум версии 0.60.0.
> А были бы autotools, мы бы никогда не читали, что нужна новая
> версия bash, dash, ksh, или иного sh.вы много пакетов за последний год собрали? какой дистрибутив, какой репозитарий?
ещё раз: Meson требуется только на этапе сборки, готовым пакетам он не нужен, при этом он в разы упрощает сопровождение больших и сложных пакетов на фоне той мерзости, что вы упомянули (это я как бывший ментейнер кое-каких пакетов opensuse говорю)
>вы много пакетов за последний год собрали? какой дистрибутив, какой репозитарий?Где-то сотню слакбилдов написал.
>Meson требуется только на этапе сборки
А кто собирать-то за юзера будет? Вася?
Стандартный способ установки пакетов в GNU -- это ./configure ; make ; make install
>>вы много пакетов за последний год собрали? какой дистрибутив, какой репозитарий?
> Где-то сотню слакбилдов написал.Давайте ссылку, посмотрим - что собирали и кому. Анончику на слово, сами понимаете, не верит никто.
>>Meson требуется только на этапе сборки
> А кто собирать-то за юзера будет? Вася?Юзер не разработчик дистрибутива, чтобы что-то собирать. Скачает готвый пакет. А если юзер не признаёт дистрибутивы - это его проблема (скорее всего клиническая). К слову юзеру никто ничего не должен пока он не оплатил соответствующую услугу. Хочется обмазаться autotools и друзьями? - Редактор в руки и пишите себе сами. И поддерживайте эту "вкусняшку" сами.
> Стандартный способ установки пакетов в GNU -- это ./configure ; make ;
> make installИ где этот стандарт? Хочу почитать, посмеяться над теми, кто на полном серьёзе стандартизирует бред.
https://www.gnu.org/prep/standards/
Конкретнее, в каком пункте стандартизовано использование autotools? Где там MUST/REQUIRED/SHALL в значении указанном в RFC2119?
Где вы в моём комментарии увидели autotools? Там было ./configure, и именно на него я вам ссылку и вручил. А с помощью чего вы его будете генерить, стандарт не определяет.
> что позволяет заметно ускорить перезапускОни правда всех за идиотов держат? Такое впечатление, что операционная система служит для того чтоб ее перегружали, перегружали, перегружали... вместо того что оно работало
> во время обновления окружений,
Ну да они ведь обновления то каждые несколько секунд приходят причем критичность взлета на несколько секунд раньше (точнее видимости что взлетело, на самом деле то в бэкграунде понасоздавали сокетов и ждутьс) ну просто ОЧЕНЬ критично
Вангую речь идет о серверах где время перезапуска а так своевременность патчей безопасности действительно важны и простои измеряются в десятках и сотнях тысяч денег. Для домашнего пользователя важность этого не так очевидна.
Ты плохая ванга. Серверы грузятся довольно долго в самом биосе, время старта ос не существенно. Где завязано столько денег обычно оно вообще никого не волнует, так-как архитектура позволяет потерять хоть ДЦ целиком.
> Серверы грузятся довольно долго в самом биосеВот именно. Мягкая перезагрузка это и фиксит.
> Ты плохая ванга. Серверы грузятся довольно долго в самом биосе,
> время старта ос не существенно.Поэтому сабж умеет ребут через kexec - чтобы применить новое ядро. Или вон то - если это было не надо. BIOS при этом в полном пролете.
>оно вообще никого не волнуетДержателей виртуалок интернет-магазинов в амазоне конечно не волнует.
> Они правда всех за идиотов держат?нет, они сами это самое и есть.
> Ну да они ведь обновления то каждые несколько секунд приходят
ну было одно время что обновления дерьмобаса сыпались как из рога изобилия, причем с не то чтоб критичными но неприятными фиксами. А дерьмобас нынче поважнее какого-то там процесса с pid 1, его перезагрузить нельзя в принципе. Только вместе с системой.
> Ну да они ведь обновления то каждые несколько секунд приходят причем критичность взлета на
> несколько секунд раньшеу кого одноразовый амазонский инстанс - тем пофигу, а у кого все еще немодный bare metal - там не секунды и не несколько, минут 15-20 современные тяжелые серверы стартуют.
Правда, в каком виде оно будет после такого вот soft-not-reboot- я лично не рискну выяснять, и мы как перезагружались целиком так и будем дальше, что бы там эти альтернативно-одаренные не наплели.
> ну было одно время что обновления дерьмобаса сыпались как из рога изобилия,
> причем с не то чтоб критичными но неприятными фиксами. А дерьмобас нынче поважнее
> какого-то там процесса с pid 1, его перезагрузить нельзя в принципе. Только вместе с системой.Видимо потому что приведет к фаллауту апликух юзавших его. Ну вот облажались гномеры с архитектурой, что поделать? Системд сам то как раз умеет себя рестартить, в отличие от. Это даже еще и работает. И кстати дбас для работы системды - опционален. Работает и без него.
> Правда, в каком виде оно будет после такого вот soft-not-reboot- я лично
> не рискну выяснять, и мы как перезагружались целиком так и будем дальшеНу правильно, твой уровень системной экспертизы не позволяет в нормальную инженерию с хорошими эксплуатационными свойствами результата. Я только не понимаю нахрен тебя фирмачи держат такого вообще.
>так и будем дальшеполезно еще от питания отсоединять
>>так и будем дальше
> полезно еще от питания отсоединятьЧтобы залететь по максимуму? Самое то. Потом рррррраз! А там толи питальник не запускается, толи батарейка у CMOS села и настройки слетели. И вы находите что искали - много гемора на ровном месте изниоткуда. Хотя для поха самое оно. Все как он любит.
> вы находите что искали - много гемора на ровном месте изниоткуда.все именно так и происходит, "работает - не трогай" - это девиз начальства, а не сисадмина :)
> Хотя для поха самое оно. Все как он любит.
а че делать если кЕтайское гамно кругом?
>> а че делать если кЕтайское гамно кругом?Давать дорогу молодым.
Ставишь систему управления цеховым конвеером на одну китайскую железяку. Косты по времени на внедрение такие, что даже бекап невозможно организовать. Лишь бы работало.
Получаешь премию за экономию.
При факапе вызываниваешь программиста в час ночи это все исправлять.
Программист, через 2 часа (пол часа на сборы, полтора на дорогу) на велосипеде приезжает и все чинит. Режешь премию программисту за факап
Получаешь премию за экономию.
> Режешь премию программисту за факап
> Получаешь премию за экономию.Программист — если не олень — за такие шутки с премией на раз-два уходит в другую компанию. В мыле ищешь кому передать все его таски. Понимаешь, что за две недели передача дел невозможна физически, а с дембельским настроением у программиста и подавно. Две недели каждую ночь снятся кошмары про факап конвейера. В ночь с пятницы на субботу второй недели кошмар оказывается реальностью. Программист не отвечает на смс и звонки с мольбами поправить всё за любые деньги. Начальство депримирует уже тебя. Уходишь в запой.
1. Не слушаешь опытных специалистов, потому, что понимаешь, что мир изменился и молодых специалистов овердофига.
2. Заставляешь писать первого програмиста логику на javascript
3. Открываешь вакансию на которую набегает 236 вайтишников
4. Устраиваешь сверхунизительные, гнобящие собеседования.
5. Находишь ботана из бедной семьи, готового ишачить как олень, на заданных условиях
6. Получаешь еще одну премию
Неолени постепенно релоцируются за бугор, оставляя чистыми пастбища с пасущимися парнокопытными
И потом вдруг понимаешь, что прекрасное далеко стало не просто близко, а именно сейчас
Да. По 2-му пункту:
>> Косты по времени на внедрение такие, что даже бекап невозможно организовать. Лишь бы работало.Делается специально, для доказательства криворукости первого програмиста при сдаче обьекта. Его с самого начала планируется увольнять. На конечном участке работы он доказывает, что он не олень трясущемуся от страха ботану под бдительным присмотром погонщика, и ему, по чистой случайности, это не удается сделать. Олень, на выход
> Программист — если не олень — за такие шутки с премией на
> раз-два уходит в другую компанию. В мыле ищешь кому передать все
> его таски. Понимаешь, что за две недели передача дел невозможна физически,Ты так хорошо описал менеджмент большей части РФовских предприятий и т.п.. А потом начинают ныть что "спецов не хватает" и "благополучие только в отчетах". Хороший пример как это все образуется. Хорошие спецы и менеджеры такой треш за километр видят и обходят. Им вон там платят в разы больше, и начальник крутой и компетентный, а не м...к-подставщик.
> все именно так и происходит, "работает - не трогай" - это девиз
> начальства, а не сисадмина :)Законы Мерфи появились кажется еще до сисадминов. Они неплохо работают. Админы лишь усвоили их. Те кто посообразительнее. А вот пох вечно проверяет их на себе зачем-то. Ну, мало ли, может он по жизни мазохист?
> а че делать если кЕтайское гамно кругом?
Например уйти из места где "кЕтайское гамно".
> А вот пох вечно проверяет их на себе зачем-то.
> Ну, мало ли, может он по жизни мазохист?К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про неё свой толк все к худу клонит;
А ежели невежда познатней,
Так он её ещё и гонит.
> Например уйти из места где "кЕтайское гамно".плюс
> Например уйти из места где "кЕтайское гамно".куда, блжад? В Рожа линукс? Или может в МЦСТ (а, стоп, опять китайское)?
> Правда, в каком виде оно будет после такого вот soft-not-reboot- я лично не рискну выяснять, и мы как перезагружались целиком так и будем дальше, что бы там эти альтернативно-одаренные не наплели.SPARC M6 стартует по-холодному около часа. Так что его *полностью* вообще не перегружают, если не конец света.
Альтернативно одаренный, my ass.
Ну так на нем и не линукс при этом ни разу.
С драйверами написанными левой задней ногой по где-то черновым или вовсе стыренным неполным спекам.Не говоря уже о самом железе, производители которого меньше всего думают о том как его инитить из не первоначального состояния, у них семь бед один ресет, времена windows95 и перезагрузок с зажатым shift они давно забыли.
"В новом режиме при перезагрузке не применяются стадии инициализации оборудования, вызова загрузчика, запуска и загрузки ядра, инициализации драйверов, загрузки прошивок и обработки initrd, что позволяет заметно ускорить перезапуск"sudo service lightdm restart - или что-то в этом роде, не катит?
На сервере не катит
Для этого придётся читать документацию, разбираться с зависимостями и составлять target. Как видно по комментарию выше, не все умеют.
Лучше бы порчу файловых систем при kexec-перезагрузке починили.
Можно пример? Желательно со ссылкой на обсуждение проблемы.
> Лучше бы порчу файловых систем при kexec-перезагрузке починили.ну а как они тебе ее починят, если при kexec не выполняется корректный шатдаун? (там не только отмонтировать fs и сбросить буфер, и проверить что сброшен а не опять как всегда, но и этого тоже не делается)
Просто забудь, эта технология не для нормальных систем.
Максимум пользы от нее - разьве что начальная установка, когда можно так запустить систему с диска после того как ее же туда и поставил, сэкономив 15 минут черного экрана. Но лучше не экономить и не бороться потом с глюками. Заодно будешь уверен что она штатным образом загружается.
Я когда-то использовал без проблем. Только без системд понятное дело, этот системд любит зависнуть когда не надо.
> Я когда-то использовал без проблем. Только без системд понятное дело, этот системд
> любит зависнуть когда не надо.это он как раз и пытается решить проблему "порчи файловых систем" как у начавшего тред рукож0па.
Получается у него как обычно, но он хотя бы - старался.
> ну а как они тебе ее починят, если при kexec не выполняется
> корректный шатдаун? (там не только отмонтировать fs и сбросить буфер, и
> проверить что сброшен а не опять как всегда, но и этого
> тоже не делается)Ты что, хотел чтобы kexec() тебе весь шатдаун системы делал? А вот и фиг, это софт секвенсировать должен - как обычный шатдаун.
А то может тебе и в reboot() кеши скидывать? Маны читайте, man 2 reboot - там честно говорят что если вы кеши не сбросили, это ваши проблемы.
> Просто забудь, эта технология не для нормальных систем.
Попорбуйте вынуть руки из известного места.
> не бороться потом с глюками. Заодно будешь уверен что она штатным
> образом загружается.У поха жизнь, видимо, резиновая...
> Ты что, хотел чтобы kexec() тебе весь шатдаун системы делал?я бы хотел чтоб его не было вовсе, поскольку нормальным системам этот костыль - не нyжен (запрещенное в край дол6анутым mc слово), они без него бегают.
Но вон там выше товарищ жалуется что у него что-то идет не так. Я ему и пытался объяснить, что.Зачем ты меня лечишь - не знаю. Видимо у тебя интеллект не позволяет понять суть цепочки реплаев.
(зато ценные советы, которых никто не спрашивал, горазд давать)> У поха жизнь, видимо, резиновая...
у меня сервер - желеный. И мне пох сколько он там перезагружается раз уж я потрудился его вывести из сервиса - через часок вспомню и схожу посмотреть как он там. Перезагружаеся он - долго прежде всего потому что процесс шатдауна - долгий и не всегда вообще заканчивается удачно. Линукс, что вы хотите. Руки из известного места. Сделать дерьмо, написать в мане, таск закрыт.
Вон не будем показывать пальцем - отдельно shutdown, а соврешенно отдельно и независимо ни от каких обстоятельств (даже в single, впрочем у нее это не "init=/bin/bash") - сброс буферов.
Но - немодно, девляпсы не знают что с ней делать.
> у меня сервер - желеныйВот это зря наверное, если нет конечно совсем уж жёстких требований к производительности.
Наличие гипервизора сильно упрощает жизнь во многих случаях.
Да, это у меня были явно пережитки прежней эпохи в сознании, когда линукс еще не был таким трэшем как сейчас.Все новые прожекты даже если они по ресурсам требуют целиком сервер - я пихаю в вмварь. Пусть оно не сможет свободно мигрировать и живет без фэйловера, но у меня не будет проблем ни с управлением, ни с корявыми установщиками, ни с неумением линуксных драйверов в FC, ни с xfs.
А та перезагрузок требует раз в три года и без фокусов.
> Все новые прожекты даже если они по ресурсам требуют целиком сервер -
> я пихаю в вмварь. Пусть оно не сможет свободно мигрировать и
> живет без фэйловера, но у меня не будет проблем ни с
> управлением, ни с корявыми установщиками, ни с неумением линуксных драйверов в
> FC, ни с xfs.Именно так, да.
> я бы хотел чтоб его не было вовсе, поскольку нормальным системам этот
> костыль - не нyжен (запрещенное в край дол6анутым mc слово), они
> без него бегают.1) Спасибо биосоклепателям, кооперативным, дружелюбным и думающим что отвисать 5 минут в блобвари круто и правильно, кладя на вой кастомеров.
2) Я знаю и более интересные применения - сделать из линя бутлоадер, когда мелкий линь сможет подчитать и запустить основной из какой-то очень сложной конфиги, требующей для раскрутки вот именно всех фич линуха. Это нишевое развлечение но по своему удобно бывает.
3) При этом еще есть такая забавная штука как "crash kernel". Позволяет извлечь кой-какое инфо из навернувшейся системы в относительно удобном виде даже если не подцеплен "хардварный" дебагер. Ты ж не тусишь с жытагом и debug-usb портами в проде?!> так. Я ему и пытался объяснить, что.
Ну дык kexec мало чем от ребута отличается, до того как это делать систему надлежит зашатдаунить. Т.е. по уму sync, remount-ro, процесы покилять, ...
>> У поха жизнь, видимо, резиновая...
> у меня сервер - желеный. И мне пох сколько он там перезагружаетсяНу то-есть либо тебе на QoS пофиг, что клиенты 15 минут без сервиса, либо на фтыкание в его экран (и тогда жизнь резиновая). Да, если бы хардвар стартовал быстро вон то не особо требовалось бы.
> прежде всего потому что процесс шатдауна - долгий и не всегда
> вообще заканчивается удачно. Линукс, что вы хотите.Ээээ... ты никогда не видел как контроллеры домена на винде шатдаунятся? ORLY? Они тоже так умеют если что :)
> Сделать дерьмо, написать в мане, таск закрыт.
Да я как-то и шатдауны AD по полчаса и более припоминаю. Это еще спасибо если апдейты не надо ставить.
> Вон не будем показывать пальцем - отдельно shutdown, а соврешенно отдельно и
> независимо ни от каких обстоятельств (даже в single, впрочем у нее
> это не "init=/bin/bash") - сброс буферов.Сам по себе сброс буферов еще не гарантирует что вон та программа не накинет туда снова так то.
> Но - немодно, девляпсы не знают что с ней делать.
Ахз, alt-sysrq-s как бы тоже оно. При том работает и с клавы, и с сериального шнурка, по сети (если разрешить) и даже записью в характерный файл - "произвольный программный критерий".
Зачем тормозит при выгрузке Плазма?
> Скрипт kernel-install переписан на языке СиНу хоть кто-то переписывает в правильном направлении
Капец, SystemD уже со всеми видами перезагрузками
Перегрузка на соседнюю машину есть?
> Перегрузка на соседнюю машину есть?Разместите там rootfs и вывесьте по какому там еще nfs, получите желаемое.
Для systemd-resolved в resolved.conf добавлен параметр StateRetentionSec, позволяющий сохранять DNS-записи в кэше, дольше, чем указано через TTL, и использовать их, если вышестоящий DNS-сервер перестал отвечать. Для просмотра содержимого DNS-кэша в утилиту resolvectl добавлена команда "show-cache".Норм затея.
>Норм затея.костыль, причем вредный
Это из тех вредных что лучше пусть будет.
>>Норм затея.
> костыль, причем вредныйесли бы был сделан как надо - т.е. ТОЛЬКО при недоступности dns вообще - в остальных случаях ttl работает как описано или вообще как написано (это две разные вещи, если что) и за уточнениями - к нормальному серверу - был бы иногда и полезный.
Но можно даже не проверять. ЭТИ _всегда_ сделают через задницу.
Удобный костыль на случай, если полсети 3.14*нулось, что-то таки продолжит работать.
[тут сразу пейсбук с их системой запирания дверей вспоминается]
> [тут сразу пейсбук с их системой запирания дверей вспоминается]так они уже наверняка починили. Ну в смысле - приняли меры чтоб рабы оказались в случае чего запертыми внутри, а не снаружи.
На подходе новая IT профессия - Systemd Engineer.
> На подходе новая IT профессия - Systemd Engineer.вот еще не хватало. Просто девляпс получит новый таск. Живей-живей-живей, галера замедлила ход!
Точнее на исходе профессия баш-инитшляпописателя
> Точнее на исходе профессия баш-инитшляпописателяникуда не делась.Просто теперь это вызывается где-то внутри юнита в виде ExecPre, сам скрипт лежит в непредсказуемом месте и при продолбе хрен сообразишь что пошло не так и где искать концы.
> никуда не делась.Просто теперь это вызывается где-то внутри юнита в виде ExecPre,
> сам скрипт лежит в непредсказуемом месте и при продолбе хрен сообразишь
> что пошло не так и где искать концы.В отличие от шелл-портянок системд все же имеет свойство ругаться в логи если не нашел программу или ее запуск обломался. И stdout/stderr программ в логи редиректит.
...а в sysv удобства во дворе, так что логер-дебагер вы себе сначала сами и накорябайте, тогда узнаете что отлипло вообще. Особенно прикольно когда при тестовом пинке от рута "интерактивно" - все на ура пашет, а вот там, в boot time - что-то не срослось.
Ды ладно. systemctl status - и всё понятно где.
>Наиболее заметным изменением в новой версии стала поддержка режима мягкой перезагрузки (команда "systemctl soft-reboot"), который приводит к перезапуску только компонентов пространства пользователя, не трогая ядро Linux. В новом режиме при перезагрузке не применяются стадии инициализации оборудования, вызова загрузчика, запуска и загрузки ядра, инициализации драйверов, загрузки прошивок и обработки initrd, что позволяет заметно ускорить перезапуск и уменьшить время простоя во время обновления окружений, использующих готовые системные образы.А ведь когда то на линуксах не любили из виндовово именно что перезапуск после каждого апдейта. Но скромный служащий корпорации Microsoft, которая, как известно, любит линукс, выдрессировал линуксоидов не ненавидеть перезагрузку системы, как и модель с одним диском цэ на всю систему.
> А ведь когда то на линуксах не любили из виндовово именно что
> перезапуск после каждого апдейта. Но скромный служащий корпорации Microsoft, которая,
> как известно, любит линукс, выдрессировал линуксоидов не ненавидеть перезагрузку системы,
> как и модель с одним диском цэ на всю систему.Это не служащий майкрософт а хаксоры и CVE. Небольшая разница. Хотя если сильно хочется, можно и либо не перезагружаться (kernel live patching) - либо мигрировать сервисы и виртуалки и там никто не замтетит что ребут хоста был. А на винде так можно вообще?
Если кто не в курсе, эта новость - продолжение вот этой https://www.opennet.dev/opennews/art.shtml?num=59099А вообще прикольно наблюдать эпопею systemd вот так https://www.opennet.dev/keywords/systemd.html