Certain system emails are not sending

jmturner commented 1 year ago

Summary

Discourse is not sending certain system emails. Test emails can be successfully sent from the UI as well as the Ruby scripts and the system successfully sends upgrade reminder emails, so the infrastructure seems correct. However, new users do not get login link emails or email confirmation emails sent. I can see nothing in logfiles to indicate why.

Steps to reproduce

Attempt to log in to Discourse
Put email/username in form.
Click "email me a login link."
No email gets sent.

What is the expected correct behavior?

Discourse should send an email to the email of the user, with a login link included.

Relevant logs and/or screenshots

Environment

Image version / tag: 3.1.0
Host OS: Debian Bullseye (running in an unprivileged LXC container on Proxmox)

Any logs | docker-compose.yml

``` version: '2.4' services: discourse-app: container_name: discourse-app image: tiredofit/discourse:latest labels: - traefik.enable=true - traefik.http.routers.discourse-example-org.rule=Host(`discourse.example.org`) # REDACTED - traefik.http.services.discourse-example-org.loadbalancer.server.port=3000 volumes: - ./logs:/data/logs - ./data/uploads:/data/uploads - ./data/backups:/data/backups environment: - TIMEZONE=America/New_York - CONTAINER_NAME=discourse-app - DB_HOST=postgresdb - DB_NAME=REDACTED - DB_USER=REDACTED - DB_PASS=REDACTED - REDIS_HOST=discourse-redis - SITE_HOSTNAME=discourse.example.org # REDACTED - CONTAINER_ENABLE_MESSAGING=TRUE - SMTP_PORT=25 - SMTP_HOST=postfix - SMTP_OPENSSL_VERIFY_MODE=none - SMTP_ENABLE_START_TLS=true - DEVELOPER_EMAILS=REDACTED@REDACTED restart: always networks: # - proxy - services extra_hosts: - postgresdb:172.17.0.1 - postfix:172.17.0.1 ports: - 2020:2020 - 8082:80 - 3001:3000 - 10150:10050 discourse-redis: image: tiredofit/redis:7 container_name: discourse-redis volumes: - ./redis:/var/lib/redis environment: - TIMEZONE=America/New_York - CONTAINER_NAME=discourse-redis - CONTAINER_ENABLE_MESSAGING=TRUE - SMTP_HOST=postfix - SMTP_PORT=25 - SMTP_OPENSSL_VERIFY_MODE=none - SMTP_ENABLE_START_TLS=true networks: - services restart: always extra_hosts: - postgresdb:172.17.0.1 - postfix:172.17.0.1 ports: - 2021:2020 - 6379:6379 - 10151:10050 discourse-db-backup: image: tiredofit/db-backup container_name: discourse-db-backup volumes: - ./dbbackup:/backup environment: - TIMEZONE=America/New_York - CONTAINER_NAME=discourse-db-backup - DB_HOST=postgresdb - DB_TYPE=postgres - DB_NAME=REDACTED - DB_USER=REDACTED - DB_PASS=REDACTED - DB_DUMP_FREQ=1440 - DB_DUMP_BEGIN=0000 - DB_CLEANUP_TIME=8640 networks: - services restart: always extra_hosts: - postgresdb:172.17.0.1 - postfix:172.17.0.1 ports: - 2022:2020 - 10152:10050 networks: proxy: services: ~ ```

I note that I do have to do a "gem install actionmailer" to get the test_email_settings.rb script to run.

I'm sadly not familiar enough with Discourse or your handy container to know where the issue lies.

Possible fixes

I am guessing a batch job somewhere (sidekiq?) is not running like it should. I don't know if the unprivileged nature of the LXC container I'm running in is the root cause. I am using the suggested 'nesting=1' which allows containers to run inside containers.

tiredofit commented 1 year ago

Strange that it works one way yet not the other. The image performs SMTP settings into the /app/config/discourse.conf file - Perhaps you would want to see if some of those settings may fix it and get it going? You'd want to pkill puma following that to let the settings be read.

jmturner commented 1 year ago

I see that two configurations are present in discourse.conf, perhaps from an append instead of a replace? The settings that are present seem correct and I can't see how multiple identical values would cause an issue but that might be another bug to track down.

I pared discourse.conf down to one configuration, pkilled puma, and attempted an email link again. Still no love. The container never attempts to connect to the mailhost. Here's what gets logged into discourse.log:

I, [2023-02-15T16:57:19.090718 #1799] INFO -- : Started POST "/u/email-login" for REDACTED-IP at 2023-02-15 16:57:19 -0500 I, [2023-02-15T16:57:19.093244 #1799] INFO -- : Processing by UsersController#email_login as / I, [2023-02-15T16:57:19.093788 #1799] INFO -- : Parameters: {"login"=>"REDACTED-EMAIL"} I, [2023-02-15T16:57:19.132247 #1799] INFO -- : Completed 200 OK in 38ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 5563) D, [2023-02-15T16:57:39.514035 #1806] DEBUG -- : Delivering messages [] to client BIGASS-UUID-REDACTED for user D, [2023-02-15T16:57:42.625406 #1795] DEBUG -- : Delivering messages [] to client BIGASS-UUID-REDACTED for user

FYI, The puma.log, puma-error.log, and sidekiq.log files are all zero-length.

tiredofit commented 1 year ago

Great eyes. Indeed its appending if the container restarts "warm". I'll fix that one up. I'm going to need to open a Dev server to look into this on my own and at the very least get more logging going for those zero byte files.

I have a mountain of things on the go right now, going to put it on my list for near future < next 10 days. I have this running in a production environment and haven't seen similar things.

I do know as well there are a few DISCOURSE_ hidden environment variables when I started reverse engineering their docker repo that may assist with getting SMTP going, I feel we just need a bit more detail - almost trace level logging instead of their logging at this time.

Lets see what I can come up with.

depau commented 1 year ago

I'm having a similar issue with a fresh container I'm trying to set up.

I can't finish the first setup procedure since it fails to send the activation email.

I verified that running the following inside the container does send an email, but the user confirmation email won't send and it won't log any errors:

bundler exec rake emails:test[testemail@example.com]

tiredofit / docker-discourse