Volver a hornear todas las publicaciones que coincidan con un patrón
Lamentablemente, eso no funcionó, la URL no cambió después de reconstruir el HTML y todavía lleva a un\n> Oops! Esa página no existe o es privada.\n\n\n¿Alguna otra idea o pensamiento?
¿Funcionó o no la reconstrucción desde la UX?
Hacer clic en el botón “Reconstruir HTML” no funcionó. El enlace no cambió y todavía lleva a la página de error.
Hay un segundo problema que noté después de la restauración. Eché un vistazo a los registros de errores y noté esto. El enlace no es el mismo que el del post que reconstruí:
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
Lo extraño es que cuando pongo la URL anterior en el navegador, sí que sirve el icono.
Aquí está el backtrace
Mensaje (5 copias reportadas)
Falló el procesamiento correcto de la respuesta secuestrada: Errno::ENOENT: No existe tal archivo o directorio @ 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:inblock (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:inblock in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:inblock in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:insynchronize' /var/www/discourse/lib/distributed_mutex.rb:29:insynchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:insynchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:inmemoize’
/var/www/discourse/app/controllers/static_controller.rb:138:inblock in favicon' /var/www/discourse/lib/hijack.rb:56:ininstance_eval’
Entonces no necesitaste averiguar cómo reconstruir desde la línea de comandos.
No estoy seguro, pero parece que lo está tratando como un nombre de archivo en lugar de un bucket, pero necesitaría ver el código fuente para saberlo con seguridad.
¿Alguna otra idea/pensamiento sobre cómo arreglar los enlaces rotos de /short-url?
Eso también me pasó a mí, en un servidor de Oracle Cloud. El kernel entró en pánico, y yo también. Pensé que estaba perdido. Pero después de unos seis u ocho reinicios desde la consola de la nube, algunos de los cuales fueron reinicios de “desenchufar el cable”, y después de esperar aproximadamente media hora, el servidor arrancó el tiempo suficiente para que pudiera editar grub.cfg y revertir al kernel anterior.
Pude salvar mi instancia de esa manera. Un día después, se ofreció otra nueva actualización del kernel, y fue entonces cuando me convencí más de que mi teoría sobre problemas del kernel era cierta. Y encontré la descripción del error para confirmarlo. Sí, bastante desagradable.
Ideé un Truco Estúpido de Grub, como lo llamo, que intentaré encontrar tiempo para publicar pronto, para que uno pueda evitar tal calamidad en el futuro.
Buena suerte con tu restauración, @RBoy. Debo decir que este hilo me da un nudo en el estómago después de mi propio desastre cercano el – ¿cuándo fue, el miércoles?
Por cierto, dijiste que recuperaste el acceso a tu antiguo servidor. Si todavía lo tienes o puedes acceder una vez más – a mí me tomó algunos reinicios forzados y algo de espera – bueno, entra y actualiza una vez más, ya que hay otro kernel nuevo que no tiene el error. O revierte al kernel anterior.