PostgreSQL завис при перестроении

Поддержка Самостоятельное хостинг
24

У меня та же проблема… У меня Droplet на Ubuntu 20.04. Сначала я пытался обновить Docker прямо из Discourse, но постоянно получал ошибку с кодом 137. Тогда я попытался пересобрать Discourse из командной строки, но процесс завис на сообщении «The database is ready to accept connections». Нажатие Ctrl+C ничего не дало, поэтому я закрыл SSH-сессию, открыл новую, снова запустил Discourse — он работал, но не был обновлён. После перезагрузки Droplet я снова попытался обновить Docker через Discourse, и на этот раз всё прошло успешно. Затем я снова попытался пересобрать Discourse, но он снова завис в том же месте. Снова закрыл SSH, открыл новую сессию и запустил Discourse, но теперь вижу экран «Oops»! Теперь мой сайт Discourse недоступен, а единственный способ, которым мне ранее удавалось восстановиться после экрана «Oops», — это пересборка приложения, что сейчас невозможно.

Теперь я в тупике, так как мой опыт работы с Discourse и Droplet очень ограничен, и я не знаю, что делать дальше. В моём файле app.yml используется только плагин docker_manager, поэтому я могу предположить, что ошибка связана с тем, что версия Docker новее и несовместима с моей версией Discourse? Не знаю. Я обновлял Discourse в последний раз в январе, так что он не так уж устарел…

Мой сайт недоступен, пока эту проблему не решат… Единственный вариант — создать новый Droplet, заново настроить всё и восстановить резервную копию Discourse, которую я сделал? Это мой единственный выход сейчас? :tired_face:

25

Ошибка 137 означает нехватку оперативной памяти. Попробуйте добавить больше файла подкачки (swap). Если у вас всего 1 ГБ ОЗУ, я бы увеличил её до 2 ГБ и, возможно, добавил 3–4 ГБ файла подкачки.

Вы можете попробовать запустить:

./launcher start app

Но, скорее всего, база данных уже слишком сильно обновилась для старого контейнера.

Если вы зашли в тупик и хотите получить платную поддержку, обратитесь по адресу Contact Us - Literate Computing

Редактирование: Вот что я бы сделал:

26

Привет, у меня та же ошибка. Пока можно обойти это, принудительно указав параметр версии v3.3.0 в app.yml. Архитектура AMD64, Ubuntu 18.04. Странно, что сбой произошел в минорной версии, а обновление до v3.3.0 на прошлой неделе прошло без проблем :neutral_face:

27

Если у кого-то возникла эта проблема и вы готовы предоставить мне доступ к вашему серверу, пожалуйста, напишите мне в личные сообщения, чтобы я мог отладить проблему на сервере, где она проявляется. Я пробовал множество способов, но не смог воспроизвести эту проблему, что затрудняет внесение исправления.

28

Я не вижу в своём профиле способа написать вам в личные сообщения…

29

Вам нужен уровень доверия 1, чтобы отправлять сообщения

Судя по статистике в вашем профиле, вы уже очень близки к этому.

30

Для тех, кто столкнулся с этой проблемой, когда Discourse не работает, я обнаружил, что можно запустить старую версию форума, перезапустив виртуальную машину и выполнив команду ./launcher start app. Эта команда не сработает после попытки пересборки без перезапуска вашего экземпляра или виртуальной машины.

В понедельник я смогу обновить версию Ubuntu на нашей затронутой виртуальной машине, поэтому буду держать всех в курсе результатов.

31

Ctrl+C не работает, когда система зависла; приходится перезагружать компьютер.

32

Эта команда также ничего не делает.

**/var/discourse**# ./launcher start app

Обнаружена архитектура x86_64.

ПРЕДУПРЕЖДЕНИЕ: файл containers/app.yml доступен для чтения всем. Вы можете защитить этот файл, выполнив: 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 запрещен, репозиторий не существует или может потребоваться 'docker login': отказано: запрошенный доступ к ресурсу запрещен.

См. 'docker run --help'.
33

У меня есть другой форум на другом Droplet, и там не возникает никаких проблем с обновлением. Странно, почему при одинаковой конфигурации сервера на одном Droplet возникают проблемы, а на другом — нет?

34

Звучит как проблема с оперативной памятью. Сколько у вас RAM и swap-памяти? Я бы добавил 1–2 ГБ пространства swap (и, возможно, увеличил RAM, если у вас всего 1 ГБ).

Сколько RAM и swap-памяти на этих системах? Какой вывод команды:

free -h

Именно нехватка RAM объясняет, почему @tgxworld не смог воспроизвести проблему.

Я почти уверен, что дело в RAM/swap.

35

Кстати, если вы столкнулись с этой проблемой, вы можете временно обойти её, добавив base_image: discourse/base:2.0.20240708-0023 в начало файла containers/app.yml.

36

Не уверен, что в моём случае это проблема с оперативной памятью, так как у затронутой виртуальной машины выделено 125 ГиБ, а доступно 78 ГБ.

              total        used        free      shared  buff/cache   available
Mem:           125G         14G        940M         31G        110G         78G
Swap:            0B          0B          0B

Сервер разработки с той же ОС, который успешно обновился без этой проблемы, имеет всего 16 ГиБ оперативной памяти.

37

Чёрт. Это должно было всё объяснить. :person_shrugging:

38

Может быть, это проблема с размером базы данных?

База данных на нашем продакшн-сервере довольно большая, а на дев-сервере — очень маленькая. Это единственное существенное различие между виртуальными машинами, которые успешно обновились, и той, которая пострадала (в моём случае).

39

Возможно, вы изменили конфигурацию памяти для базы данных?

Какого размера ваша база данных?

40

Я проверю и посмотрю, не изменилось ли что-то

41

Это единственное, что сработало для меня. Спасибо, что поделились этим!! Мои клиенты тоже благодарят вас :slight_smile:

Надеюсь, что скоро мы получим правильное исправление этой проблемы.

42

Здравствуйте,
Я только что увеличил размер Droplet, удвоив объём оперативной памяти и увеличив размер диска. Проблема всё ещё сохраняется.
Есть ли что-то ещё, что можно попробовать?

# 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
43

О боже! Почему я не прочитал это решение раньше. Это тоже помогло мне.
Так какое решение будет актуально в будущем? Нужно ли и дальше указывать этот базовый образ или его следует менять для получения обновлённого образа?