Помощь в восстановлении: система зависла в полночь

Пересобрать все сообщения, соответствующие шаблону

К сожалению, это не сработало: URL-адрес не изменился после перестроения HTML, и он по-прежнему ведёт на страницу

Упс! Эта страница не существует или закрыта.

Есть ли ещё какие-то идеи или мысли?

Сработала ли перестройка на основе UX или нет?

Нажатие на кнопку «Rebuild HTML» не сработало. Ссылка не изменилась и по-прежнему ведёт на страницу ошибки.

После восстановления я обнаружил ещё одну проблему. Я посмотрел логи ошибок и заметил следующее. Ссылка не совпадает с той, что была в восстановленном посте:
Failed to process hijacked response correctly : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico

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

Вот трассировка стека:

Сообщение (5 копий)

Failed to process hijacked response correctly : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico

Backtrace

/var/www/discourse/app/controllers/static_controller.rb:160:in read' /var/www/discourse/app/controllers/static_controller.rb:160:in block (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:in block in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:in block in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:in synchronize' /var/www/discourse/lib/distributed_mutex.rb:29:in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:in synchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:in memoize’
/var/www/discourse/app/controllers/static_controller.rb:138:in block in favicon' /var/www/discourse/lib/hijack.rb:56:in instance_eval’

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

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

Есть ещё какие-то идеи или соображения, как исправить битые ссылки на /short-url?

Со мной тоже такое случилось на сервере Oracle Cloud. Ядро паниковало, и я тоже. Думал, всё пропало. Но после примерно шести-восьми перезагрузок через консоль облака, некоторые из которых были «выдергиванием штекера», и после примерно получаса ожидания сервер поднялся на достаточно долгое время, чтобы я мог отредактировать grub.cfg и откатиться к предыдущему ядру.

Мне удалось сохранить свой экземпляр. Спустя день было предложено ещё одно новое обновление ядра, и именно тогда я стал ещё увереннее в своей теории о проблемах с ядром. Я нашёл описание бага, которое это подтвердило. Да, довольно неприятно.

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

Удачи с восстановлением, @RBoy. Должен сказать, эта ветка вызывает у меня тошноту после моего собственного почти катастрофического случая на прошлой неделе — когда это было, в среду?

Кстати, вы сказали, что получили доступ к своему старому серверу. Если он у вас всё ещё есть или вы можете получить к нему доступ снова — для меня это заняло несколько жёстких перезагрузок и некоторое ожидание — так вот, зайдите и обновитесь ещё раз, поскольку есть другое новое ядро, в котором нет этого бага. Или откатитесь к предыдущему ядру.