복구 도움 요청 - 자정에 시스템이 멈춤

제품 지원 자체 호스팅
24

패턴에 일치하는 모든 게시물을 다시 생성

25

불행히도 그 방법은 효과가 없었습니다. HTML을 다시 빌드한 후에도 URL이 변경되지 않았고, 여전히 다음과 같은 오류가 표시됩니다.

Oops! That page doesn’t exist or is private.

다른 아이디어나 생각이 있으신가요?

26

UX 작업으로 재구축을 한 건가요, 안 한 건가요?

27

“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을 브라우저에 입력하면 실제로 아이콘이 제공된다는 것입니다.

아래는 백트레이스입니다.

Message (5 copies reported)

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’

28

그렇다면 커맨드 라인에서 다시 빌드하는 방법을 알아낼 필요가 없었을 것입니다.

확실하지는 않지만, 버킷이 아닌 파일 이름으로 취급하는 것 같습니다. 확실하게 알기 위해서는 소스 코드를 확인해 봐야 합니다.

29

/short-url 깨진 링크를 수정하는 방법에 대해 다른 아이디어나 생각이 있으신가요?

30

저도 오라클 클라우드 서버에서 같은 일이 발생했습니다. 커널이 패닉 상태에 빠졌고, 저도 마찬가지였죠. 완전히 끝장난 줄 알았습니다. 하지만 클라우드 콘솔에서 6~8회 정도 재부팅을 하고(그중 일부는 전원 차단 방식의 재부팅이었으며), 약 30분 정도 기다린 끝에 서버가 기어이 올라와서 grub.cfg를 편집하여 이전 커널로 되돌릴 수 있었습니다.

그 덕분에 인스턴스를 살릴 수 있었습니다. 하루가 지난 후, 또 다른 새로운 커널 업데이트가 제안되었고, 그때서야 제 커널 문제 관련 추측이 맞다는 확신이 더 커졌습니다. 그리고 버그 설명을 찾아 이를 확인했습니다. 네, 꽤 심각한 문제였죠.

저는 이를 '멍청한 그루브 트릭(Stupid Grub Trick)'이라 부르는 방법을 고안했습니다. 시간이 나면 나중에 게시해 보려 합니다. 그러면 이런 재앙을 미래에 피할 수 있을 테니까요.

복구 작업이 잘 되길 바랍니다, @RBoy. 솔직히 말씀드리면, 지난번(언제였죠, 수요일?) 제가 겪은 아찔한 사고 이후로 이 스레드를 보면 속이 안 좋아집니다.

참고로, 당신은 이전 서버에 다시 접근할 수 있었다고 했습니다. 만약 여전히 해당 서버를 가지고 있거나 다시 접근할 수 있다면 – 제 경우에는 몇 번의 강제 재부팅과 기다림이 필요했죠 – 들어가서 한 번 더 업그레이드해 보세요. 버그가 없는 또 다른 새로운 커널이 있습니다. 아니면 이전 커널로 되돌리는 것도 방법입니다.