chaus
8월 30, 2024, 8:40오전
24
저도 같은 문제를 겪고 있습니다… DO Droplet에 Ubuntu 20.04를 사용하고 있습니다. 처음에는 Discourse 안에서 Docker를 업그레이드하려고 시도했지만, 계속 오류 코드 137이 발생했습니다. 그래서 커맨드 라인에서 Discourse를 재구축(rebuild)하려고 했는데, The database is ready to accept connections 단계에서 멈춰버렸습니다. Ctrl+C를 눌러도 아무 반응이 없어서 SSH를 닫고 새로 연 뒤 Discourse를 다시 시작했는데, 사이트는 작동하긴 했지만 업데이트는 되어 있지 않았습니다. Droplet을 재부팅한 후 Discourse에서 다시 Docker 업그레이드를 시도했는데, 이번에는 성공했습니다! 그런데 다시 Discourse 재구축을 시도하자 같은 위치에서 또 멈춰버렸습니다. 다시 SSH를 닫고 연 뒤 Discourse를 시작했는데, 이번에는 Oops 화면이 나타났습니다! 이제 제 Discourse 사이트가 다운된 상태이며, 이전에 Oops 화면에서 복구할 수 있었던 유일한 방법은 앱을 재구축하는 것이었는데, 지금은 그게 불가능합니다!
지금 저는 당황한 상태입니다. Discourse와 Droplet 사용 경험이 매우 제한적이어서 지금 무엇을 할 수 있을지 모르겠기 때문입니다. 제 app.yml에서 사용하는 유일한 플러그인은 docker_manager이므로, Docker 버전이 더 최신이라 제 Discourse 버전과 호환되지 않아서 오류가 발생한 것 같다는 추측만 하고 있습니다. 확실하지는 않습니다. Discourse를 마지막으로 업데이트한 시점이 1월이므로 그렇게 오래된 버전은 아닙니다…
이 문제가 해결될 때까지 제 사이트는 다운된 상태입니다… 아니면 새로운 Droplet을 시작해서 모든 것을 다시 설정하고, 제가 백업해둔 Discourse 백업을 복원하는 수밖에 없을까요? 지금 저에게 선택지는 그것뿐인가요?
pfaffman
8월 30, 2024, 9:01오전
25
에러 137은 메모리 부족을 의미합니다. 스왑 공간을 더 추가해 보시길 권합니다. RAM이 1GB뿐이라면 2GB로 확장하고, 스왑 공간도 3~4GB 정도 확보하는 것이 좋습니다.
아래 명령어를 시도해 볼 수 있습니다.
./launcher start app
하지만 구버전 컨테이너에는 데이터베이스 마이그레이션이 너무 많이 진행되어 문제가 될 가능성이 높습니다.
막혀 있는 부분이 있고 유료 지원이 필요하시다면 Contact Us - Literate Computing 을 참고해 주세요.
수정: 하지만 제가 하겠다라면 다음과 같이 하겠습니다:
안녕하세요, 저도 같은 오류가 발생합니다. 당분간 임시 조치로 app.yml에서 버전 파라미터를 v3.3.0으로 강제 지정하는 방법입니다. 아키텍처는 AMD64, OS는 Ubuntu 18.04입니다. 마이너 버전 업데이트가 실패한 것이 좀 이상하네요. 지난주에는 v3.3.0으로 업데이트할 때 아무 문제 없이 잘 되었는데요
tgxworld
8월 30, 2024, 10:02오전
27
이 문제를 겪고 계신 분 중 서버에 대한 접근 권한을 부여하는 데 불편함이 없으시다면, 문제를 겪고 있는 서버에서 디버깅할 수 있도록 개인 메시지를 보내 주세요. 여러 가지 방법을 시도해 보았지만 이 문제를 재현할 수 없어 수정 사항을 배포하기가 더 어려워졌습니다.
chaus
8월 30, 2024, 12:10오후
28
프로필에서 쪽지를 보낼 수 있는 방법을 찾지 못하겠습니다…
Moin
8월 30, 2024, 12:13오후
29
메시지를 보내려면 신뢰 수준 1이 필요합니다
Jeff Atwood:
다음 방법으로 신뢰 수준 1을 달성하세요.
최소 5 개의 주제에 참여하기
최소 30 개의 게시물 읽기
게시물 읽기에 총 10 분 이상 투자하기
프로필의 통계를 보면 이미 거의 다 된 것 같습니다
Discourse가 다운된 상태에서 이 문제로 막혀 계신 분들을 위해, VM을 재시작한 후 ./launcher start app을 실행하면 최소한 구버전의 포럼은 실행할 수 있다는 것을 발견했습니다. 인스턴스/VM을 재시작하지 않고 재구축을 시도한 후에는 이 명령어가 작동하지 않습니다.
월요일에 영향을 받은 VM의 Ubuntu 버전을 업그레이드할 수 있을 것 같으니, 결과를 확인하는 대로 모두에게 알려드리겠습니다.
sallypf
8월 30, 2024, 1:32오후
31
시스템이 멈추면 Ctrl+c가 작동하지 않아 시스템을 재부팅해야 합니다.
sallypf
8월 30, 2024, 1:34오후
32
이 명령도 아무 효과가 없습니다.
**/var/discourse**# ./launcher start app
x86_64 아키텍처가 감지되었습니다.
경고: containers/app.yml 파일이 모든 사용자(world)에게 읽기 권한이 있습니다. 다음 명령을 실행하여 이 파일을 보호할 수 있습니다: chmod o-rwx containers/app.yml
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=techoforum.com -e DISCOURSE_DEVELOPER_EMAILS=techoforumd@gmail.com -e DISCOURSE_SMTP_ADDRESS=smtp.sendgrid.net -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=apikey -e DISCOURSE_SMTP_PASSWORD=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 -e DISCOURSE_SMTP_DOMAIN=gmail.com -e DISCOURSE_NOTIFICATION_EMAIL=techoforumd@gmail.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h discourseonubuntu2004-s-1vcpu-1gb-sfo3-01-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f8:99:7d:c3:d6 local_discourse/app /sbin/boot
로컬에서 'local_discourse/app:latest' 이미지를 찾을 수 없습니다
docker: 데몬에서 오류 응답: local_discourse/app에 대한 pull 액세스가 거부되었습니다. 리포지토리가 존재하지 않거나 'docker login'이 필요할 수 있습니다: 거부됨: 요청한 리소스에 대한 액세스가 거부되었습니다.
'docker run --help'을(를) 참조하십시오.
sallypf
8월 30, 2024, 1:43오후
33
다른 드롭렛에 또 다른 포럼이 있는데, 그곳에서는 업데이트에 문제가 전혀 없습니다. 서버 구성이 동일한데 왜 한 드롭렛에서만 문제가 생기고 다른 곳에서는 그렇지 않은지 이상합니다.
pfaffman
8월 30, 2024, 2:01오후
34
RAM 문제인 것 같습니다. RAM과 스왑 공간이 각각 얼마나 있나요? 스왑 공간을 1~2GB 정도 추가하고 (RAM이 1GB뿐이라면 RAM도 추가하는 것이 좋습니다) 해보세요.
해당 시스템들의 RAM과 스왑 용량은 각각 얼마인가요? 다음 명령어의 출력 결과는 무엇인가요?
free -h
RAM 용량이 @tgxworld가 문제를 재현하지 못하는 이유를 설명해 줄 수 있을 것입니다.
RAM/스왑이 문제라고 확신합니다.
tgxworld
8월 30, 2024, 2:22오후
35
참고로 이 문제를 겪고 있는 분들을 위해, containers/app.yml 파일의 상단에 base_image: discourse/base:2.0.20240708-0023을 추가하면 당분간 우회할 수 있습니다.
Jay Pfaffman:
free -h
제 경우 RAM 문제인지는 확실하지 않습니다. 해당 VM에는 125GiB가 할당되어 있고 78GB가 사용 가능합니다.
total used free shared buff/cache available
Mem: 125G 14G 940M 31G 110G 78G
Swap: 0B 0B 0B
이 문제 없이 성공적으로 업그레이드된 동일한 OS를 사용하는 개발 서버는 RAM이 16GiB밖에 없습니다
DB 크기 문제일까요?
우리 프로덕션 서버의 데이터베이스는 꽤 큰 반면, 개발 환경의 데이터베이스는 매우 작습니다. 성공적으로 업그레이드된 VM과 영향을 받은 VM(제 경우) 사이에는 이것이 유일한 실질적인 차이점입니다.
pfaffman
8월 30, 2024, 3:13오후
39
혹시 데이터베이스의 메모리 설정을 변경해 보셨나요?
데이터베이스의 크기는 얼마나 되나요?
제게는 이것이 유일하게 효과가 있는 방법이었어요. 공유해 주셔서 감사합니다!! 제 고객분들도 감사해합니다
곧 적절한 수정이 이루어지기를 바랍니다.
sallypf
9월 1, 2024, 8:05오후
42
안녕하세요,
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 289Mi 83Mi 11Mi 1.6Gi 1.5Gi
Swap: 2.0Gi 3.0Mi 2.0Gi
# df -h
Filesystem Size Used Avail Use% Mounted on
udev 941M 0 941M 0% /dev
tmpfs 198M 1.1M 197M 1% /run
/dev/vda1 34G 14G 21G 39% /
tmpfs 986M 0 986M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 986M 0 986M 0% /sys/fs/cgroup
/dev/vda15 105M 7.4M 97M 8% /boot/efi
/dev/loop1 56M 56M 0 100% /snap/core18/2829
/dev/loop2 56M 56M 0 100% /snap/core18/2823
/dev/loop3 92M 92M 0 100% /snap/lxd/29619
/dev/loop0 64M 64M 0 100% /snap/core20/2264
/dev/loop4 64M 64M 0 100% /snap/core20/2318
/dev/loop5 39M 39M 0 100% /snap/snapd/21465
/dev/loop6 92M 92M 0 100% /snap/lxd/24061
/dev/loop7 39M 39M 0 100% /snap/snapd/21759
tmpfs 198M 0 198M 0% /run/user/0
overlay 34G 14G 21G 39% /var/lib/docker/overlay2/3c7ebf42647de2b5df34cba2b047079fd3454ea7fe9b04c7b70f227df1e7eafe/merged
sallypf
9월 1, 2024, 8:36오후
43
오마이갓! 왜 이 해결책을 먼저 읽지 않았을까요. 저에게도 잘 작동했습니다.
