어젯밤 Ubuntu 20.04 LTS가 자동으로 업그레이드되면서 이 문제를 겪었습니다. 새 커널이 설치된 후 시스템 제어가 불가능해졌고, 부팅 후 몇 분 만에 크래시가 발생했습니다. 오늘 새로운 Discourse 설치를 시도했는데, 시스템 업그레이드와 동시에 다시 크래시가 시작되었습니다.
참고로, 아직 Linux 커널을 업데이트하지 마시기 바랍니다. 이는 알려진 버그이며, 자세한 내용은 아래 링크를 참조하세요.
문제는 Discourse/docker를 시작하지 않고 시스템을 시작할 수 있는 방법이 있는지입니다. AWS Lightsail에서 실행 중입니다. 다른 유일한 선택지는 현재 백업/복원 문제로 인해 매우 번거로운 전체 시스템 재구축입니다.
수정: 이것이 제가 찾은 방법입니다. 시스템이 얼마나 빨리 시작되느냐에 따라 결과가 달라집니다.
while true; do
ssh <instance> "sudo systemctl disable docker.service; sudo systemctl disable containerd.service"
done
저도 두 대의 EC2 인스턴스에서 동일한 문제가 발생했습니다. 동부 표준시(EDT) 오전 5시에 재부팅을 위해 서버가 종료된 후 다시 기동되지 않았습니다.
링크에 따르면, 이는 Ubuntu 머신에서 공식 "클라우드 커널"을 실행하는 사용자들에게 영향을 미칩니다. OverlayFS에 영향을 미치는 패치가 제거되었습니다.
Canonical이 수정 사항을 배포하는 동안, 사용자는 다른 커널 버전을 사용하거나 Debian/다른 배포판을 사용하는 방식으로 임시 해결책을 시도할 수 있습니다.
시작 후 약 15초 만에 SSH로 접속하여 docker/컨테이너 서비스를 비활성화함으로써 사이클을 중단할 수 있었습니다. 커널을 5.4로 다운그레이드한 후 정상적으로 작동하는 것 같습니다.
네, 방금 다른 스레드인 복원 문제에서 언급했듯이, 이 버그로 서버가 충돌했을 때 제가 한 조치도 기본적으로 동일했습니다. 저는 구버전 커널로 부팅했을 뿐이고, docker나 컨테이너를 비활성화할 필요는 없었습니다. 그리고 현재 커널은 다시 안전합니다. 다른 스레드에서 제가 말한 내용은 여기 링크를 참고해 주세요. 잠시 후 다시 이런 일이 일어나지 않도록 하기 위한 영구적인 해결책을 정리해서 올리겠습니다.
정말 악독한 커널 버그였네요!
이전 커널로 되돌리기만 하면 시스템이 복구됩니다. 아니면 목요일에 배포된 최신 수정 커널로 업데이트할 수도 있습니다.
서버를 충돌시키거나 재부팅을 막는 이러한 문제를 일으키는 커널 오OPS!를 피하는 방법에 대한 튜토리얼을 작성했습니다.
편리할 것 같아서 튜토리얼을 제 디스커스(Discourse) 사이트에 올렸습니다. 제 사이트는 기술과는 전혀 관련이 없지만요. 그래서 해당 주제를 비공개로 설정하되 HTML로 공개했습니다.
즐기세요.
https://discourse.bluebottlefly.com/pub/hardening-your-server
@RBoy, 특히 이 내용이 유용할 것 같습니다.
/dr