PostgreSQL 재빌드 중 멈춤

안녕하세요,

앱을 다시 빌드하려고 했을 때 PostgreSQL 시작 문제 때문에 어려움을 겪고 있어 도움을 요청합니다.

아래는 로그입니다. 이 상태로 30분 이상 멈춰 있습니다.

Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-08-26T17:16:15.344712 #1]  INFO -- : Reading from stdin
I, [2024-08-26T17:16:15.357924 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.362740 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.367767 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.372845 #1]  INFO -- : File > /root/install_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377501 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377876 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.378854 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379386 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379835 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380263 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380761 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381203 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381901 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382352 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382802 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383231 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383604 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*::1\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.384079 #1]  INFO -- : > if [ -f /root/install_postgres ]; then
  /root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi

2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused
I, [2024-08-26T17:16:15.452500 #1]  INFO -- : Generating locales (this might take a while)...
Generation complete.

I, [2024-08-26T17:16:15.453058 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-08-26T17:16:15.455944 #1]  INFO -- : Terminating async processes
2024-08-26 17:16:15.500 UTC [30] LOG:  starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv6 address "::", port 5432
2024-08-26 17:16:15.507 UTC [30] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-26 17:16:15.516 UTC [31] LOG:  database system was interrupted; last known up at 2024-08-26 17:10:28 UTC
2024-08-26 17:16:15.769 UTC [31] LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-26 17:16:15.774 UTC [31] LOG:  redo starts at 18F/E62D1458
2024-08-26 17:16:15.774 UTC [31] LOG:  invalid record length at 18F/E62D1490: wanted 24, got 0
2024-08-26 17:16:15.774 UTC [31] LOG:  redo done at 18F/E62D1458
2024-08-26 17:16:15.809 UTC [30] LOG:  database system is ready to accept connections```

그래서 프로세스가 깨끗하게 종료되지 않았고, 스스로 문제를 해결하려 했으며, 그렇게 했다고 생각하는 것 같습니다.

일단 Ctrl+C로 프로세스를 종료한 뒤, ./launcher start app 명령을 실행하여 기존 컨테이너가 다시 실행되는지 확인해 보세요.

정상적으로 작동한다면, 다시 ./launcher stop app을 실행한 후 재빌드해 보세요.

최근 며칠 동안 재빌드를 시도하면서 같은 문제를 겪고 있습니다. Discourse를 문제없이 실행하거나 재빌드하는 데 실패하고 있습니다.

시작/중지 기능을 사용해 보았지만 효과가 없었습니다. VM 자체도 몇 번 재시작해 보았습니다. 그런데도 계속 데이터베이스가 연결을 받을 준비가 되었다는 줄에서 멈춰 있습니다.

Ctrl+C가 작동하지 않았고, 이전 버전으로 되돌리기 등 여러 가지 방법을 시도해 보았지만, 재빌드를 시도하자마자 정확히 같은 위치에서 멈춰 버렸습니다.

RAM 용량은 얼마인가요? 네트워크 연결이 느린가요?

제 문제와 관련해서… RAM은 넉넉합니다… 8GB. 네트워크도 정상입니다

4GB RAM, 네트워크, 디스크 사용량, CPU 사용량, RAM 사용량까지 모두 확인해봤는데, 전부 정상으로 보입니다.

드디어 좀 더 진전을 이뤘습니다. 서버의 /var/discourse/ 디렉터리에서 커밋 b1108913820edd27f869634d0fc654639758889a를 체크아웃했습니다. 이 커밋은 며칠 전 것으로, discourse_docker 히스토리에서 이 세 가지 커밋(1, 2, 3)을 포함하지 않습니다. 이 중 하나의 변경 사항이 postgres가 멈추는 문제의 원인이라고 의심하고 있습니다.

어쨌든 결국 앱을 다시 구동할 수 있었습니다. 정말 끔찍한 경험이었네요 ㅋㅋ

3.3.0에서 3.3.1로 업그레이드할 때 동일한 문제가 발생합니다. 업그레이드가 동일한 로그 줄(데이터베이스 시스템이 연결을 수락할 준비가 되었습니다)에서 멈춰 있습니다.

재부팅하거나 업그레이드 프로세스를 종료한 후 ./launcher start app를 실행하면 해결됩니다. 새 버전 3.3.1이 표시됩니다. 하지만 이것이 적절한 절차인지 확신이 서지 않습니다.

그러니까 문제 있는 사람이 네 명인 것 같습니다.

그중 ARM에서 문제가 발생한 분과 Intel에서 문제가 발생한 분을 나눠 주실 수 있을까요?

좋은 질문입니다.

저는 새로운 Digital Ocean VM에 새로 설치한 후 재빌드(rebuild)를 실행해 봤는데, 아무 문제 없이 잘 작동했습니다.

저는 인텔(Intel)을 사용하고 있습니다.

문제를 해결한 방법은 새로운 드롭렛(droplet)을 생성하고 새 설치를 한 뒤, 백업을 복원하는 것이었습니다. 이렇게 하면 재빌드(rebuild)가 정상적으로 작동합니다.

정상적으로 작동하는 버전의 백업도 가지고 있는데(약간 오래된 버전입니다), 재빌드를 통해 최신 버전으로 업그레이드하는 순간 동일한 문제가 발생했습니다. 그래서 최근 커밋에 도입된 무언가가 이전 버전에서 최신 버전으로의 업데이트만 깨뜨리는 것 같다고 의심하고 있습니다.

아, 그렇군요.

음. 서버가 내려가도 괜찮은 사이트를 찾아보겠습니다.

아마도 표준 1-컨테이너 표준 설치 환경이시겠네요. 그런 환경을 찾아볼게요.

위 커밋 이후에도 같은 문제를 겪고 있어 이 문제를 다시 올립니다. 위에 언급된 방법들을 모두 시도해 보았지만 문제가 해결되지 않았습니다.

x86입니다. 호스트 OS는 ubuntu bionic을 사용 중인데… 이것이 영향을 미칠 수 있습니다. 다른 분들의 OS가 무엇인지 확실하지 않습니다.

이미 EOL(지원 종료)이 1년 이상 지난 상태입니다. Ubuntu 18.04 EOL – keep your fleet of devices up and running | Ubuntu.

새 VM을 생성하고 그곳으로 이전할 시점이 아직 이르다고 할 수 없습니다.

문제를 조사하는 데 도움이 될 추가 정보입니다.

Ubuntu 18.04.6이 설치된 한 호스트에서 이 문제가 발생하고 있습니다. 하지만 다른 호스트도 오늘 동일한 버전의 Ubuntu로 업데이트되었음에도 Discourse 재빌딩은 정상적으로 진행되었습니다.

영향을 받은 호스트의 Ubuntu를 업그레이드해 보겠습니다. 이렇게 하면 도움이 될지 확인해 보겠습니다. 진행 상황을 계속 공유하겠습니다.

영향을 받으신 분들은 아래 명령어를 실행하여 출력 결과가 아래와 다른지 확인해 주시겠습니까?

drwxr-xr-x  2  101 104 4.0K Aug 29 01:33 postgres_backup
drwx------ 19  101 104 4.0K Aug 29 01:42 postgres_data
drwxrwxr-x  3  101 104 4.0K Aug 29 01:42 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 01:38 redis_data
# ls -lahn /var/discourse/shared/standalone/ | grep -E "postgres|redis" 
drwxr-xr-x  2  101 104 4.0K Dec 26  2019 postgres_backup
drwx------ 19  101 104 4.0K Aug 28 03:59 postgres_data
drwxrwxr-x  5  101 104 4.0K Aug 28 03:59 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 03:59 redis_data

재빌드 문제가 발생한 VM의 출력 결과:

drwxr-xr-x  2  101 104 4.0K Jun 15  2020 postgres_backup
drwx------ 19  101 104 4.0K May  3  2022 postgres_data
drwxrwsr-x  5  101 104 4.0K May  3  2022 postgres_run
drwxr-xr-x  2  103 106 4.0K May  3  2022 redis_data

참고로, 제 경우에는 약간 다른 상황이었습니다.
다른 분들이 겪은 것처럼 재빌드가 The database system is ready to accept connections 단계에서 멈췄습니다. VM을 재부팅하고 ./launcher start app을 실행해야 포럼을 시작할 수 있었습니다. 그러나 Discourse가 다시 구동되었을 때, Discourse 버전은 이전 버전인 3.3.0.beta4-dev로 유지되었습니다.

오늘은 Ubuntu 업그레이드를 수행할 수 없었지만, 가능할 때와 재빌드가 성공적인지 여부에 대해 계속 공유하겠습니다.

오늘 개발용 인스턴스를 Ubuntu 20.6으로 업그레이드했는데, 재빌드/업그레이드가 Discourse 3.4.0.beta2-dev로 성공적으로 완료되었습니다. 다만, 이 호스트는 어제 Ubuntu 18.4에서도 문제 없이 재빌드된 적이 있습니다.