같은 데이터 센터 내의 드롭렛(droplet) 간에 /var/discourse를 rsync로 동기화하면 다운타임을 상당히 줄일 수 있으며, 폴백은 DNS를 되돌리는 것뿐입니다.
새로운 VPS에는 docker와 필요에 따라 스왑(swap)만 있으면 됩니다.
안녕하세요,
저도 Red Hat Enterprise Linux 7을 실행할 때 이 오류가 발생합니다. 커널 버전은 3.10.0입니다. RHEL8은 크게 새로운 버전이 아닙니다.
저도 마찬가지입니다. CentOS7(3.10.0-1160.76.1.el7.x86_64)에서 3.1.0.beta1이 정상적으로 실행되고 있습니다.
분명히 디스트로 커널에는 많은 백포트가 적용됩니다. 이 방식처럼 바닐라 커널 버전을 확인하는 것이 다른 프로젝트에서도 문제를 일으킨 적이 있습니다. 커맨드 라인에서 이 체크를 우회할 수 있는 방법이 있을까요?
—업데이트—
런처 스크립트를 수정하여 체크를 우회했습니다. 여러 CentOS7 설치 환경에서 문제없이 업데이트되었습니다.
이 이슈에 대해 더 많은 조명이 쬐게 될까요? 시스템 요구 사항에는 커널 버전이 명시되어 있지 않으며, CentOS 7/RHEL 7은 아직 EOL(지원 종료) 상태가 아닙니다. Docker 역시 더 새로운 커널을 요구하지 않습니다. 수동으로 체크를 우회하는 것은 장기적으로 적절한 해결책이 아니라고 생각합니다.
오래된 포럼을 업그레이드하려던 중 동일한 오류가 발생했습니다. CentOS 7은 아직 EOL(종료)이 되지 않았는데, Ubuntu 14.04에 대한 대안 해결책을 찾아 주실 수 있을까요?
OS 공급업체에서 제공하는 최신 커널(백포트된 수정 사항 포함)을 실행 중이라고 생각한다면, 해당 검사를 우회하는 방법을 시도해 볼 수 있습니다. 저라면 그렇게 할 것입니다. 이곳은 해당 검사가 추가된 이슈입니다. ./launcher 스크립트의 다음 단락에서 exit 명령을 제거하거나 주석 처리하면 될 것 같습니다:
# At least minimum version
if compare_version "${kernel_min_version}" "${test}"; then
echo "ERROR: Kernel version ${test} not supported, please upgrade to at least ${kernel_min_version}"
exit 1
fi
그럼에도 불구하고 업그레이드가 계속 실패한다면, 더 새로운 커널에서 Discourse를 실행할 방법을 찾아야 합니다.
(이 조언이 주제에서 벗어났다고 느껴질 수 있지만, 제 생각에는 버전 번호에 대한 검사보다는 기능(예: urandom)에 대한 검사가 이루어져야 하는데, 현재 방식은 오탐(false positive)을 일으킬 수 있습니다.)
지금 이 문제를 겪고 있으며, 이로 인해 포럼이 다운되어 있습니다. 런처 스크립트를 편집하여 커널 확인 부분을 주석 처리하는 방법(최소한 CentOS 7이 해당 업데이트를 받거나 포럼을 다른 서버로 이전할 때까지)을 알려주실 수 있을까요?
업데이트:
시도錯誤 끝에 런처를 업데이트하는 데 성공했습니다. 커널 확인 부분을 주석 처리하는 대신 요구 사항으로 더 낮은 버전을 지정했는데, 잘 작동했습니다.
이것이 장기적인 해결책은 아닐 수 있지만, 호스팅 업체에서 CentOS 7에는 4.4 커널 버전이 제공되지 않을 것이라고 이미 통보해 왔습니다… 이것이 실용적인 측면에서 어떤 의미를 갖는지 설명해 주실 수 있나요?
CentOS 7은 2024년 중반까지 업데이트를 받을 것으로 보입니다.
어느 시점에는 - EOL(지원 종료) 이전일 수도 있습니다 - 끊임없이 발전하는 Discourse가 CentOS 7에는 없는 기능이 필요하게 될 것이며, 이때 운영체제를 업그레이드하거나(또는 적절한 OS 버전을 갖춘 새로운 인스턴스로 이전해야 합니다.) 해당 시점에 아직 도달하지 않은 것으로 보입니다.
항상 그렇듯이, 현재나 향후 Discourse를 업데이트하기 전에 포럼의 백업을 수행하고, 해당 백업과 app.yml 파일의 안전한 사본을 확보해 두시기 바랍니다.
방금 재구축한 것과 함께 작동하는 커널 버전은 무엇인가요?
만약 4.4보다 낮은 버전인데도 작동한다면, @falco가 요구되는 커널 버전을 다시 낮춰야 할 것 같습니다.
(배포판은 이후 커널의 기능 및 수정 사항을 백포트하기 때문에, 커널 버전 확인은 매우 무딘 도구입니다. 지원 부담을 줄이려는 의도는 이해하지만, 안전성 검사에서 오탐이 발생하면 반대 효과가 나타납니다. 그리고 Discourse가 인기를 얻으면 얻을수록 이 문제는 더 커집니다. 버전을 확인하는 것보다 기능을 확인하는 것이 훨씬 낫습니다.)
저희 시스템은 다음을 실행 중입니다:
- CentOS Linux release 7.9.2009 (Core)
- Kernel 3.10.0-1160.88.1.el7.x86_64
업데이트 내용:
현재 포럼은 정상적으로 작동하고 있지만, 이 오류가 점점 더 자주 발생하고 있습니다:
어서
이 토론 포럼을 구동하는 소프트웨어에서 예상치 못한 문제가 발생했습니다. 불편을 드려 죄송합니다.
오류에 대한 자세한 정보가 기록되었으며 자동 알림이 생성되었습니다. 확인하겠습니다.
추가 조치는 필요하지 않습니다. 다만 오류 상태가 지속될 경우, 오류 재현 방법 등을 포함한 추가 세부 사항을 사이트의 피드백 카테고리에 토론 주제를 게시하여 제공할 수 있습니다.
이것이 최소 커널 요구 사항 문제와 관련이 있을까요? 이 ‘불안정성’(이렇게 부를 수밖에 없습니다)은 지난 며칠/몇 주 동안 더 두드러지게 느껴졌습니다. 포럼이 정상인 때도 있고, 그렇지 않은 때도 있는 것처럼 왔다 갔다 합니다.
수정: 신경 쓰지 마세요. 이것은 postgresql 문제(컨테이너가 없는 이미지와 관련된 프로세스가 너무 많이 실행되고 있는 것)와 관련이 있었던 것 같습니다. 런서 클리업으로 해결되었습니다.
저도 이 의견에 동의합니다. @Falco님, 이 방식이 좋은 방법이라고 생각하시나요?
네, 올바르게 기능 감지하도록 하는 PR을 환영합니다.
Falco님,
Discourse를 3.1.0.beta2에서 3.1.0.beta4로 업데이트하려고 할 때 이 문제를 겪었습니다.
이것은 단순한 마이너 업그레이드처럼 보였지만, 커널 확인 항목 때문에 CentOS 7에서는 업데이트 과정이 훨씬 복잡했습니다. 다음에는 변경 사항의 상대적으로 큰 영향을 더 잘 반영할 수 있는 다른 버전 번호를 사용하는 것이 좋겠습니다.
토론 내용을 읽어보았지만, 실제로 어떤 기능 확인이 필요한지 정확히 파악하기가 어렵습니다. 이 부분에 대해 좀 더 자세히 설명해 주시면 누군가가 PR을 제출할 수 있을 것입니다.
@Ed_S 님의 게시물에 있습니다:
Ruby 3.1에서는
Random.urandom이 제대로 구현되지 않은 플랫폼(커널 3.13이 설치된 Ubuntu 14.04를 실행하는 사용자 포함)에서 이를 호출할 때 RuntimeException이 발생합니다.