жду ебилдов!

Кстати, а до этого нельзя было так делать? Есть же kexec.

Для kexec надо завершить все процессы и только тогда вызвать kexec и запустить все снова. Профит только в скипании биоса. Тут ничего перезапускать не нужно - все вживую.

то перезагрузку раз в полгода на несколько минут они переживут.

И тут fsck на N-терабайтном разделе... Ага, уже слышу «не используй ext-fs». :-)

Кстати, у меня тут внезапно завёлся друг дуалбутчик. Когда я ставил ему бубунту, я выбрал Legacy режим UEFI. Теперь чтобы загрузить вендовоз 8.1 и полюбоваться на получасовую загрузку он идёт в биос и через его дебри ставит режим UEFI.
Ведь для kexec вообще пофиг, что грузить, значит можно загрузить и вендовоз. Думаю, можно для него написать простенькую утилитку для загрузки венды. Нужно только сразу продумать путь к отступлению и иметь ещё противоположную утилитку для загрузки линуксов из венды. Думаю, сейчас это будет востребовано.

kexec? или как тут устроено?

Ну вот представь, себе продакт сервер крупного банка занятой транзакциями финансовых операций, или например торговой биржы. Перерыв в работе не допустим, а нашли в ядре баг, который ложит систему, дает удаленно рута, или уничтожает данные на дисках, что будешь делать? Правильно - надо быстрее накатить патч, устранить баг, причем не останавливая процессы. Для этого это и нужно. Про плановые работы все и так в курсе.

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

Kexec в винду? Ага, щаз.

подскажите как уменьшить базовую версию в opensuse

на твердотельном диске от 2Гб осталось 200 Мб. диск 256Мб и debian (неужели это решение)

праздник для аптаймодрочеров

Лучше сформулируй нормально и создай топик. Я ничего не понял.

на десктопах у нас есть волшебный системд и мы можем ребутиться хоть каждые 5 минут! ведь теперь ребут стал на 50% быстрее и на 70% вкуснее!*

*по версии лёни поттера

Надо будет затестить

NetInstall или сделать сборку в SUSEStudio

По-моему не нужно. Обновлять ядро без перезагрузки это всё-равно, что мотор самолёта в полёте менять.

Он установил сусю на двухгигабайтный SSD, жалуется, что осталось всего 200мб свободного места, и спрашивает, как уменьшить занимаемое сусей место.

А я про то же. Необходимость обновлять ядро «на горячую» - одна из проблем встающих перед конторами с одним сервером. И решение этих проблем - это поощрение камикадзе-подхода к инфраструктуре.

только вот ядро надо обновлять чаще чем раз в полгода.

но да, штука не очень полезная, все равно фейловер должен быть.

У крупного банка один сервер без репликаций???? Да пусть он сдохнет вместе с таким банком.

Как обычно, изобретением костылей.

Вбрасывай тоньше. Если руки из задницы растут - тут даже линуксом не поможешь.

Позитивная новость, джва года ждал

Как обычно, изобретением костылей.

КГ/АМ. Ну есть, допустим, уязвимость переполнения буфера в TCP-стеке. Изобрети-ка мне внеядерный костыль.

С репликацией и прочим. Однако, свитчовер на стендбай приведет к простою в несколько минут, чего хочется избежать. К тому же, на стендбаях, как правило, не прогреты кеши, что приведет к временным проблемам с производительностью.

А 256Мб и Debian тут причём?

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

Есть куча кривых инфраструктур, где, несмотря на важность какой-либо системы, нет дублирования. Слышал про такую вещь, как технический долг?

Есть куча инфраструктур, в которых дублирование есть, но переключение на резерв идёт с некоторый ненулевой паузой. Ну, пока VRRP отработает, пока слейв БД в мастера превратится и т. д.

Сабж применим и полезен очень во многих случаях. Если конкретно тебе это не нужно - что ж, очень за тебя рад.

Замораживает все процессы, обновляет функции и структуры в памяти в соответствии с изменениями в коде ядра на основе информации из ELF-объектов. После - процессы выполняются как если не было никакой перезагрузки.

Весело будет, если в новом ядре поломают совместимость и после разморозки процесс(ы) будут падать с segfault.

Это касается только обновлений безопасности, даже не минорная версия. Плюс, там, где это делают, очевидно, проводится многократное предварительное тестирование.

Такой подход бы сработал, но для этого нужен некий протокол, который содержит инфорацию об обновлении, чтобы в случае несовместимости возможность «обновления без перезагрузки» не была доступной. Такой протокол уже есть? Где хранится эта информация? Или админ на свой страх и риск выполняет «обновление ядра без перезагрузки»?

думал что debian сможет на 256 Мб поместиться

если есть другая ос с ядром и gcc в 256 Мб для POSIX 1.1 было бы не плохо

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

Информация об обновлении берётся из diff-а. Несовместимостей в пределах patch-версии быть не должно.

А в чем тогда смысл обновлений ? После полуобновленного ядра багов будет еще больше

Перезагружаться надо.

внезапно да?

Если не кластер и не облако, а резервирование есть - то очень нужная весч - просто бэкапы на время простоя не влияют

А ты больше слушай упоротых федорастов, которые, кстати, недавно стали применять win-style подход к обновлениям, только вот накатываются они с двумя перезагрузками, а не с одной как в винде.

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

Отличная штука. А всем, кому не надо, могут продолжать ребутаться.

С двумя? =))) К успеху идут :)

Рассматривайте ребут для апгрейда как учебную аварийную ситуацию. Посмотреть насколько гладко произойдёт переключение на резерв, что можно сделать для того, чтобы производительность в такие моменты падала некритично.

Всяк лучше чем когда пожар, а вы не готовы и система в стрессовой ситуации никогда не тестировалась.

Так отрегулируй периодический прогрев кэшей. Плановая перезагрузка для обновления даёт отличную возможность потестировать поведение в стрессовой ситуации тогда, когда это несёт минимум неудобств пользователям, а не когда годовой отчет и внезапно падает один из серваков.

вобще круто

А что это я сижу? Пойду и перезагружу ещё сервер с помощью systemd.

вобще круто

Отличная штука. А всем, кому не надо, могут продолжать ребутаться.

Пока подожду, не знаю как меня спасут патчи безопасности, если обеспечу возможность собирать модули ядра.

Если тебе подвозят мотор, то почему бы и нет? Особенно если меняется он за несколько секунд в планировании.

В основном в банках уже везде кластер, но есть серверы которые не в кластере - при перезагрузке прерывают работу банка минимум минут на 30 - частенько вижу лица довольных клиентов которых застала эта процедура :)

Учебную ситуацию я сам при тестировании создам. В продакшене любая пауза в обслуживании(даже если в договоре они указаны, даже если заранее предупредили) - повод для недовальства клиента. Можно, но зачем?

Если даже клиент согласен с паузой в обслуживании, он скорее всего попросит подождать до конца рабочего дня, или до конца ответственного мероприятия и т. п. То есть некоторые время сервис будет крутиться с уязвимостью.

Ну и самое главное - кривые/плохие инфраструктуры, которых в реальности очень много, если не большинство. Как правило, вложение денег/времени в оптимизацию происходит только когда совсем припрёт. А проектирование делается по принципу «пофиг как, но нужно ещё вчера и денег не дадим». По крайней мере, в большинстве не-айтишных контор дела обстоят именно так. Так что есть много инфраструктур, в которых критичные сервисы срутятся на единственно сервере, и для них такая штука очень пригодится.

Если тебе подвозят мотор, то почему бы и нет? Особенно если меняется он за несколько секунд в планировании

Здесь приоритетом должна быть надёжность и безопасность, а не удобство и скорость. Мотор может не завестись или начать работать неправильно, став источником трудно объяснимых глюков.