System never sends Set Password/Reset Password emails, although other emails are sent fine

We are running Bitnami’s version of Discourse here, so perhaps something is wacky because of this, though I doubt it.

Just upgraded to 1.9.0.beta4, and the problem persists, which is this:

No matter what I do, I cannot get the system to send out ANY email for password change/reset.

  • Pressing [Set Password] button in profile – Says email sent. But nothing in Email-Sent list.
  • Pressing [Reset Password] button from admin on a user – Says email sent. But nothing in Email-Sent list.
  • Pressing [Forgot Password] button upon login – Says email sent. But nothing in Email-Sent list.

Wierd thing is, all OTHER emails are sent just perfectly fine.

As such, my forum right now has the unique restriction of never being able to change passwords for any user. Anyone who forgets his/her password I need to delete the old account, and create a new one. This is a huge hassle.

I’ve searched through the Internet and doesn’t seem to find any solution to this.

We don’t support bitnami installs here.

What we really recommend is using our official install guide, where we guarantee emails are all delivered.

I was afraid you’re gonna say that…

But my company runs on Azure and there isn’t an easy way out of it…

Our default install run just fine on Azure.

OK, I’ll give it a shot.

Do you know if it works with the Azure Docker containers? Or do I have to spin up a complete Linux VM for it?


I recommend just using a complete Ubuntu VM and running the default installer there.

However, if you are experienced with Linux/Cloud/Docker you can:

  • Bootstrap the image somewhere

  • Push the bootstraped image to a Docker registry somewhere

  • Deploy the bootstrapped image

Bonus points if you do it behind a load balancer, using managed PostgreSQL and Redis, using a CDN, sharing a block storage for compiled assets, automatic scaling with health check, etc… The rabbit hole goes on.


OK great.

Will it also setup postgresql and the database and everything else in one go?

Yes, the default install bundles everything inside the docker container for minimum amount of manual intervention.


Cool. Will try it then.

1 Like

Just a note here, we like Bitnami just fine but we can only support the Docker based installation due to engineering time constraints.

Is your sidekiq listening to all queues (default,low and critical)? Those mails are using the critical queue.


Hhhmm… no idea. There was once that it says sidekiq was not running. I restarted the VM and it went away.

But still the set password mails failed to send.

Is there anyway to check the status of the critical queue?

@codinghorror Actually I have nothing against Bitnami… they are quick to setup and no fuss. However, their instructions are horrible and the installation procedure very very unforgiving – you make a mistake or you forget to copy down the admin password which flashes by ONCE, then it is off you go to do it all over again.

There is a huge long list of steps just to update Discourse to another version, and throughout the way things happen to make you go wtf. Also, their forums are hardly any help at all. is great, except that I hit on a problem saying port 80 is occupied but eventually I got through it. Probably needs a section warning the user against this.

The cloud install instructions are written assuming you’re using a fresh machine with nothing else running on it. If you’re in a different situation, then yes, you’ll have to do some things differently, but if the instructions came with caveats for every possible installation variation, it’d be huge and confusing.


As per this query, I went into /sidekiq and lo and behold… there are 79K messages queued on Sidekiq, with more than half of them in the critical queue (and others in low). The default queue is empty.

Checking the critical queues indicate that most of them are Jobs::RunHeartbeat jobs. I’m quite sure that this is not normal, and should be why I’m seeing such weird behavior.

Then under the Busy tab I find that the process is listening only to default. It is not listening to low and critical for some reason.


Now the other mystery is, why it won’t listen to low and critical… Upon a VM restart it still only listens to default. More investigations in order…


Because Bitnami has misconfigured Sidekiq – or rather, they didn’t update the configuration when Discourse started using multiple queues quite a while ago.

Issues like this are why we can only support the Docker-based installation method.