После установки Discourse с использованием “Docker version 20.10.5, build 55c4c8” на CentOS 8 сайт запущен, но запросы DELETE к /draft.json всегда завершаются по тайм-ауту.
У меня запущен Apache, и я пробовал как обратный прокси через Apache, так и через HAProxy — поведение одинаковое.
Не знаю, связано ли это, но в файле unicorn.stdout.log я вижу множество подобных ошибок:
==> ./shared/standalone/log/rails/unicorn.stdout.log <==
2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 119
2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 121
53:M 18 Mar 2021 17:07:05.076 * 10 изменений за 300 секунд. Сохранение...
53:M 18 Mar 2021 17:07:05.076 * Фоновое сохранение запущено процессом 25018
25018:C 18 Mar 2021 17:07:05.126 * База данных сохранена на диск
25018:C 18 Mar 2021 17:07:05.127 * RDB: 2 МБ памяти использовано механизмом copy-on-write
53:M 18 Mar 2021 17:07:05.177 * Фоновое сохранение завершено успешно
53:M 18 Mar 2021 17:12:06.097 * 10 изменений за 300 секунд. Сохранение...
53:M 18 Mar 2021 17:12:06.098 * Фоновое сохранение запущено процессом 25337
25337:C 18 Mar 2021 17:12:06.145 * База данных сохранена на диск
25337:C 18 Mar 2021 17:12:06.145 * RDB: 2 МБ памяти использовано механизмом copy-on-write
53:M 18 Mar 2021 17:12:06.198 * Фоновое сохранение завершено успешно
Я по-прежнему не могу удалять сообщения, приглашения и отменять изменения сообщений.
Кажется, проблема во всех вызовах метода HTTP DELETE. Могу ли я сказать, что Discourse использует POST вместо DELETE? Похоже на How can Discourse make POST instead of DELETE for "smart" CDN?, но я не использую CDN, только обычный виртуальный сервер с установкой Centos и Docker по инструкциям с сайта Discourse.
Часть лога Haproxy с ошибками 408 при HTTP DELETE. Что может «отбрасывать» запросы DELETE, @codinghorror? Если эти запросы DELETE доходят до haproxy, они должны также дойти до приложения внутри Docker. Может ли что-то там быть «виновным» в этой проблеме?
Это означает, что ваш обратный прокси настроен неверно и отбрасывает запросы, отличные от GET/POST. Это довольно распространённая проблема, и одна из причин, по которой мы поставляем контейнер с уже настроенным обратным прокси, чтобы пользователям не пришлось разбираться с этим вручную.
Если убрать HAProxy и позволить самому контейнеру слушать порты 80/443, проблема всё ещё сохраняется?
Мы используем методы DELETE/PUT во всём приложении для каждой установки и не наблюдаем никаких проблем, поэтому, вероятно, дело в чём-то специфичном для вашей установки.
На всякий случай, у вас есть WAF какого-либо типа, стоящий перед этим доменом, @Andrea_Giovacchini?
Я попробовал альтернативную установку после того, как официальная версия дала ту же проблему.
Теперь я снова попробовал официальный метод установки (discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub), но он завершается ошибкой при выполнении команды “./launcher rebuild app” с следующим сообщением (два дня назад ошибка не возникала, но тоже была связана с проблемой DELETE):
Убедитесь, что команда `gem install libv8 -v '8.4.255.0' --source 'https://rubygems.org/'` выполняется успешно перед запуском bundler.
В файле Gemfile:
mini_racer версии 0.3.1 зависит от
libv8
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:220:in `handle_error'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:102:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:71:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:270:in `install_in_parallel'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:210:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:90:in `block in run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:12:in `block in lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `open'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:72:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:24:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli/install.rb:64:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:259:in `block in install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/settings.rb:115:in `temporary'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:258:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:37:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
I, [2021-03-20T23:42:40.998961 #1] INFO -- : Завершение асинхронных процессов
I, [2021-03-20T23:42:40.998991 #1] INFO -- : Отправка сигнала INT для 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 pid: 66
I, [2021-03-20T23:42:40.999030 #1] INFO -- : Отправка сигнала TERM для exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 183
2021-03-20 23:42:40.999 UTC [66] LOG: получен запрос на быстрое завершение работы
183:signal-handler (1616283760) Получен сигнал SIGTERM, планирование завершения работы...
2021-03-20 23:42:41.013 UTC [66] LOG: отмена активных транзакций
2021-03-20 23:42:41.014 UTC [66] LOG: фоновый рабочий процесс "logical replication launcher" (PID 75) завершился с кодом выхода 1
2021-03-20 23:42:41.016 UTC [70] LOG: завершение работы
183:M 20 Mar 2021 23:42:41.058 # Пользователь запросил завершение работы...
183:M 20 Mar 2021 23:42:41.058 * Сохранение финального снимка RDB перед выходом.
183:M 20 Mar 2021 23:42:41.061 * База данных сохранена на диск
183:M 20 Mar 2021 23:42:41.061 # Redis готов к выходу, пока...
2021-03-20 23:42:41.263 UTC [66] LOG: система баз данных завершена
ОШИБКА
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' завершилась с кодом возврата #<Process::Status: pid 348 exit 5>
Место возникновения ошибки: /pups/lib/pups/exec_command.rb:112:in `spawn'
Ошибка выполнения с параметрами {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}
9b0ca932a7dd52ccdd11e268910e3edcd8369c0c08f65e7f8686d542b9be473b
** НЕ УДАЛОСЬ ЗАПУСТИТЬ БУСТЕР ** пожалуйста, прокрутите вверх и поищите более ранние сообщения об ошибках, их может быть несколько.
./discourse-doctor может помочь диагностировать проблему.
➜ discourse git:(master) ✗
@Falco я попробовал официальный сценарий установки, но вместо ветки stable использовал tests-passed. Ошибки с мини-библиотекой mini_racer больше нет, но проблема с DELETE всё ещё сохраняется, как видно в видео: в логах nginx с tail и в браузере с открытой консолью.
POST-запросы сразу появляются в логах nginx, а DELETE — только после ошибки, что странно.
Понятно. Поскольку проблему невозможно воспроизвести на новой установке, я считаю, что эту тему можно закрыть. Если проблема возникнет снова, пожалуйста, создайте новую тему с описанием шагов воспроизведения.
Команда curl выдаёт ошибку CSRF, и запрос сразу появляется во внутренних логах nginx в Discourse, но удаление через интерфейс не работает, а запись в логе появляется с задержкой около 35 секунд, как в видео, которое я отправил.
Если я указываю discourse.apicolturaitalianafb.it:8880 как имя хоста в app.yml, пересобираю и перехожу по адресу http://discourse.apicolturaitalianafb.it:8880, всё работает нормально, но я не могу использовать его таким образом.
Поскольку у меня уже запущен Apache с продакшн-сайтом, я попробовал разместить Discourse за HAProxy, как описано в документации на этом сайте, и удаление через Discourse перестало работать, хотя команда curl работает. Я также пробовал обратный прокси через Apache: curl работает, а удаление через Discourse — нет. Пробовал настроить Discourse на работу через unix-сокет и делать обратный прокси к нему, но проблема остаётся той же.
Для меня очевидно, что обратный прокси не «ломает» удаление, но какой-то JavaScript в Discourse по какой-то причине перестаёт корректно выполнять HTML-удаления.
Ваша свежая установка, которую вы пробовали, была напрямую доступна извне?
.