메일링 리스트에서 마이그레이션을 완료했으며, 많은 사용자가 여전히 이메일을 통해 포럼을 주로 이용하고 있습니다.
메일링 리스트 모드로 설정된 사용자는 약 300명입니다. 하지만 새로운 토픽이 추가될 때 Discourse는 대략 75~80통의 메일만 발송하는 것 같습니다.
여러 멤버의 메일링 리스트 사용자 설정을 비교해 보았지만, 모두 동일합니다.
건너뛴 항목(skipped section)에는 아무것도 없습니다.
이 문제를 일으킬 수 있는 원인이 어디에 있는지 어디서부터 찾아봐야 할지 모르겠습니다.
모든 사용자의 계정이 활성화되어 있나요? 메일을 받지 못하고 있는 건 아닐까요?
네, 모두 활성화되어 있습니다.
불행히도 랜덤하게 발생하는 것 같습니다. 저는 설정을 위해 몇몇 계정을 사용하는데, 그것들도 서로 다르게 동작합니다.
여기서 몇 가지 오래된 게시물을 살펴봤는데, 이 링크의 내용과 비슷해 보입니다: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
같은 문제일 수도 있습니다. 하지만 해당 게시물의 해결책에서 제안한 설정을 변경하는 방법을 모르겠습니다.
아래와 같이 실행을 시도하고 있습니다:
User.find_by_username(‘Neuer.test’).mailing_list_mode
하지만 다음과 같은 에러가 발생합니다:
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
Mailing list mode는 user_options 테이블에 설정됩니다. UserOption.where(mailing_list_mode: true)를 실행해 보세요. 메일링 리스트 모드가 활성화된 모든 사용자의 ID를 가져오려면 UserOption.where(mailing_list_mode: true).pluck(:user_id)를 실행하세요.
감사합니다 @simon
게시글에서 제안하신 대로 목록을 생성해 보았습니다. 실제로는 여러 개의 목록이 생성됩니다. User ID 목록을 생성하다가 약 50개쯤에서 :...skipping...라고 표시되고, 다시 같은 User ID로 시작하여 맨 아래에 새 ID를 하나씩 추가하면서 이 과정을 약 4~5회 반복합니다. 그 사이에 빈 줄만 가득한 섹션이 하나 있습니다. 하지만 이것이 정상적인 동작일 수도 있나요?
어쨌든, 이는 Mailing List Mode로 구독된 사용자의 완전한 목록과는 거리가 멉니다(58개만 나옵니다. 약 350개를 예상하고 있습니다).
그 후 ID 몇 개를 검사해 보았는데, 예를 들어 마지막 게시물을 받은 사람이 아무도 없었습니다.
또한 UserOption.where(mailing_list_mode: false).pluck(:user_id)를 실행해 보니 29개의 항목이 더 나왔습니다.
UserOption.where(mailing_list_mode: 1).pluck(:user_id)를 실행한 결과도 true와 비슷한 숫자가 나왔고, 사용자는 동일했습니다.
결론적으로, 활성화된 400명의 사용자 중 약 90명만 찾을 수 있었습니다. 매우 이상하고 무슨 일이 일어나고 있는지 이해가 되지 않습니다.
도움 주시면 감사하겠습니다.
P.s. 검색 결과 하단의 마지막 : 이후에서 어떻게 나가야 다시 다른 쿼리를 실행할 수 있나요?
쿼리가 화면에 표시할 수 있는 것보다 더 많은 텍스트를 반환하면, 이를 줄을 줄여서 표시합니다. 동작 원리는 구글에서 검색해 보시면 됩니다.
Space(공백) 키는 다음 화면으로 이동하고, /는 검색, q는 종료입니다.
따라서 현재 활성 사용자들에게 메일이 전달되고 있는 것으로 보입니다. 다른 사용자들은 비활성 상태일 수 있습니다.
Jay, 감사합니다.
아니요, 활성 사용자가 450명 이상입니다. 며칠 전의 이전 게시물을 살펴봤는데, 당시에는 메일링 리스트 모드로 334명의 사용자에게 발송되었습니다.
그 이후로 변한 유일한 것은 구글로 메일 전송에 문제가 있어서 DNS에 SPF 레코드를 추가했다는 점입니다. 하지만 그것은 메일 서버에서 한 작업이었으며, Discourse의 SMTP 설정은 변경하지 않았습니다.
@pfaffman 방금 Data Explorer를 설치했는데, 거기에 실행할 수 있는 쿼리가 있을까요?
이제 진짜 머리가 아파오기 시작한다 
336명이 최근 게시물을 여러 개씩 받았으니 어떻게든 ‘해결된 것’ 같다고 생각해서 게시하려고 했었다.
그런데 바로 뒤에 같은 사용자의 두 개의 답글이 연달아 올라왔다. 181명의 회원이 두 메시지 모두를, 38명이 한 개의 메시지를 받았고, 나머지 117명은 이메일을 전혀 받지 못했다.
이 상황을 조금이나마 파악할 수 있을 만한 다른 로그가 어딘가에 있을까? Sidekiq에는 아무것도 없다.
문제는 IP 주소에서 연결이 너무 많다는 421.4.7.0 오류인 것으로 보입니다.
어떤 이유에서인지 주로 한 회원에게서 발생하는 것 같습니다.
이 문제를 어떻게 수정할 수 있을까요?
로그에 표시된 내용은 다음과 같습니다:
메시지 (1957건 보고됨)
Job exception: 421 4.7.0 dd27022.xxxxxx.com Error: too many connections from xxx.xxx.xx.xxx
### Backtrace
/usr/local/lib/ruby/2.6.0/net/smtp.rb:969:in `check_response'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.1/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.1/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now'
actionmailer-6.0.1/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:113:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:212:in `send'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:90:in `block (2 levels) in execute'
/var/www/discourse/app/models/email_log.rb:35:in `block in unique_email_per_post'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/email_log.rb:31:in `unique_email_per_post'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:89:in `block in execute'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:238:in `block in in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `loop'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:135:in `find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:69:in `find_each'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:61:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.4/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.4/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.4/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.4/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.4/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.4/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.4/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.4/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.4/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.4/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.4/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.4/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.4/lib/sidekiq/util.rb:24:in `block in safe_thread'
이메일 제공업체에 문의하셔야 합니다. Discourse와는 전혀 무관합니다.
@codinghorror
이메일 제공업체를 변경했고, 이제 Amazon SES를 통해 메일을 보내고 있습니다. 처음 몇 주 동안은 이 방법으로 문제가 해결된 것 같았습니다. 하지만 다시 Discourse가 메일링 리스트 구독자에게 메일을 전송하는 도중 무작위로 전송을 중단하기 시작했습니다. 로그에는 오류가 표시되지 않습니다. 컨테이너를 재빌드했는데, 지금은 다시 정상적으로 작동하는 것 같습니다. 잠재적인 오류 로그를 확인해 볼 수 있는 다른 곳이 있을까요?
Sidekiq에서 대기 중인 작업이 있나요?
아니요, 불행히도 없습니다.
최근 며칠 동안 비슷한 문제를 겪고 있습니다. 메일링 리스트 사용자에게 이메일이 전송되지 않고, Sidekiq에 잡이 쌓여 있지도 않으며, 동일한 로그 오류가 발생하고 있습니다. 재구성을 시도해 보았지만 차이가 없는 것 같습니다. 이는 우리 사용자들에게 큰 불편을 초래하고 있습니다.
재구성 후 새 게시글이 수신되면 한 번은 전송되지만, 그 이후의 게시글/답글은 전송되지 않는 것 같습니다.
도움 주시면 감사하겠습니다!
Ed
이 문제는 나에게 정말 답답한 상황이 되고 있습니다.
오늘 Discourse가 메일링 리스트 구독자에게 이메일을 15개만 전송한 후 전송을 중단했습니다. 이미 제공업체를 변경했으므로 제공업체 문제는 아닙니다. 또한 로그에 오류 메시지가 없으며 sidekiq에 작업이 쌓여 있는 것도 아닙니다.
이 문제를 해결하는 유일한 방법은 재구축(rebuild)인 것 같습니다.
주어진 시간 간격으로 재구축을 자동으로 예약할 수 있는 방법이 있을까요? 그렇게 해야면 계속 상황을 모니터링할 필요가 없으니까요.
크론 작업을 설정해서 그 일을 처리할 수 있습니다.
일부 사용자의 경우 하루 최대 이메일 수에 도달하지 못한 건가요? 이메일을 비활성화하지 않은 건가요? (그렇다면 재구성이 문제를 해결하는 이유를 설명할 수는 없죠). RAM이 충분한가요? 로그에 아무것도 없나요?
out of memory는 꽤 명확한 에러 메시지입니다.
수정: 아, 실수했습니다. 다른 주제와 혼동해서, 멀티사이트에 관한 이 내용은 모두 사실이지만 여기서는 맥락이 맞지 않을 수 있습니다.
멀티사이트 전용 인스턴스가 4GB RAM으로 실행되고 있다고 꽤 확신합니다. 하지만 그 인스턴스에는 mysql, apache, wordpress가 함께 실행되지 않습니다. 제 사이트는 (staging + production)*(discourse + wordpress) 구성이었으며, 8GB로 증설하기 전에 문제가 많았습니다. 여기에는 postgres, redis, traefik, prometheus, mariadb 컨테이너가 각각 하나씩, 그리고 WP와 Discourse용 컨테이너가 각각 두 개씩 포함되어 있습니다. 스테이징 환경은 프로덕션과 다른 플러그인을 사용할 수 있어야 하므로 멀티사이트가 아닙니다.
비용 절감이 최우선이고 트래픽이 적은 Discourse 사이트를 운영 중이라면, 각 사이트를 1GB 용량의 $5 드롭렛에 따로 두는 것이 가장 좋은 방법일 것입니다.
네, 알았어요 
저는 표준 공유 CPU를 사용 중이며, 드롭렛에 Discourse 사이트 하나만 실행하고 있습니다.