Если вы используете rsync для синхронизации /var/discourse между droplets в одном дата-центре, время простоя может быть минимальным, а откат — просто возврат DNS.
Новому VPS требуются только Docker и, возможно, swap-раздел.
Если вы используете rsync для синхронизации /var/discourse между droplets в одном дата-центре, время простоя может быть минимальным, а откат — просто возврат DNS.
Новому VPS требуются только Docker и, возможно, swap-раздел.
Привет,
У меня тоже возникает эта ошибка при работе с Red Hat Enterprise Linux 7 с ядром 3.10.0. RHEL8 не имеет значительно более новой версии.
У меня то же самое: 3.1.0.beta1 работает нормально на CentOS 7 (3.10.0-1160.76.1.el7.x86_64).
Очевидно, что в дистрибутивных ядрах содержится множество бэкпортов. Проверка версии «ванильного» ядра таким способом уже вызывала проблемы и в других проектах. Есть ли способ обойти эту проверку из командной строки?
—ОБНОВЛЕНИЕ—
Я отредактировал скрипт запуска, чтобы обойти проверку — несколько установок CentOS 7 обновились без проблем.
Получит ли эта проблема больше внимания? Системные требования не указывают конкретные версии ядра, а CentOS 7/RHEL 7 ещё не достигли конца срока поддержки. Docker также не требует более нового ядра. Я считаю, что ручное обходное решение проверки не является правильным в долгосрочной перспективе.
Я собирался обновить старый форум и столкнулся с той же ошибкой. CentOS 7 ещё не достиг конца срока поддержки. Не могли бы вы предложить альтернативное решение для Ubuntu 14.04?
Если вы считаете, что используете самую актуальную версию ядра от поставщика вашей ОС (с бэкпортированными исправлениями), возможно, стоит попробовать обойти эту проверку. Я бы точно так поступил! Здесь описана задача, в которой была добавлена эта проверка. Мне кажется, вы можете просто удалить или закомментировать команду exit в вашем скрипте ./launcher, в этом фрагменте:
# Минимально необходимая версия
if compare_version "${kernel_min_version}" "${test}"; then
echo "ОШИБКА: Версия ядра ${test} не поддерживается, пожалуйста, обновитесь как минимум до ${kernel_min_version}"
exit 1
fi
Если после этого обновление всё равно не удастся, вам потребуется найти способ запустить Discourse на более новой версии ядра.
(Вполне возможно, что этот совет сочтут неуместным, но, на мой взгляд, проблема в том, что у нас есть проверка по номеру версии, а не по наличию конкретной функции (urandom), и такой подход может давать ложноположительные результаты.)
Я столкнулся с этой проблемой прямо сейчас, и наш форум недоступен из-за этого. Как я могу отредактировать скрипт запуска и закомментировать проверку ядра (по крайней мере, до тех пор, пока CentOS 7 не получит это обновление, или мы не перенесем форум на другой сервер)?
ОБНОВЛЕНИЕ:
Мне удалось (методом проб и ошибок) обновить Launcher, и вместо того, чтобы закомментировать проверку ядра, я просто указал более низкую версию как требование. Всё сработало отлично.
Возможно, это не лучшее долгосрочное решение, но наша хостинг-компания уже сообщила, что CentOS 7 не получит версию ядра 4.4… Не мог бы кто-нибудь объяснить, что это означает на практике?
Похоже, что CentOS 7 будет получать обновления до середины 2024 года.
В какой-то момент — возможно, даже до окончания срока поддержки — постоянно развивающаяся платформа Discourse потребует функций, которых нет в CentOS 7, и вам придётся обновить операционную систему (или перенести данные на новый экземпляр с подходящей версией ОС). Судя по всему, этот момент ещё не наступил.
Как всегда, перед попыткой обновления Discourse — сейчас или в будущем — сделайте резервную копию ваших форумов, сохраните её в надёжном месте, а также сделайте безопасную копию файла app.yml.
Какое ядро вы используете, которое работает с только что выполненной пересборкой?
Если это версия ниже 4.4 и она работает, то, похоже, @falco нужно снова снизить требуемую версию.
Поскольку дистрибутивы часто включают обратную портировку функций и исправлений из более новых версий ядра, проверка версии ядра является слишком грубым инструментом. Я понимаю идею снижения нагрузки на поддержку, но есть и обратный эффект: когда проверка безопасности выдаёт ложноположительный результат. И по мере роста популярности Discourse эта проблема становится всё серьёзнее. Намного лучше проверять наличие конкретной функции, чем версию ядра.
Наша система использует следующее:
Обновление:
Хотя наш форум сейчас работает, мы всё чаще видим эту ошибку:
Ой
Программное обеспечение, управляющее этим форумом обсуждений, столкнулось с неожиданной проблемой. Приносим извинения за неудобства.
Подробная информация об ошибке была зафиксирована в логах, и было сгенерировано автоматическое уведомление. Мы разберёмся в этом.
Никаких дополнительных действий не требуется. Однако, если ошибка повторяется, вы можете предоставить дополнительные детали, включая шаги для воспроизведения ошибки, создав тему в разделе обратной связи на сайте.
Может ли это как-то быть связано с проблемой минимальных требований к ядру? Эта «нестабильность» (назовём это так) стала более заметной в последние дни/недели. Она то появляется, то исчезает: иногда форум работает нормально, а иногда — нет.
РЕДАКТИРОВАНИЕ: Забудьте, я думаю, это было связано с проблемой PostgreSQL (слишком много запущенных процессов, связанных с образами без контейнеров; это было исправлено очисткой лаунчера).
Гораздо лучше проверять наличие функции, чем версию
Я склонен согласиться с этим. Как ты думаешь, это хорошая идея, @Falco?
Да, приветствуем PR для корректного определения этой функции.
Привет, Фалько,
Я столкнулся с этой проблемой при попытке обновить Discourse с версии 3.1.0.beta2 до 3.1.0.beta4.
Это казалось незначительным обновлением, но из-за проверки ядра обновление на CentOS 7 оказалось гораздо более сложным. Возможно, в следующий время другой номер версии лучше отразит относительно высокое влияние изменений.
Прочитав обсуждение, я не могу точно сказать, какая проверка функции действительно необходима. Возможно, если вы сможете подробнее рассказать об этом, кто-то сможет отправить запрос на слияние (PR).