A user reports their Discourse site is stuck in ‘read only’ mode and seeks help. pfaffman provides a solution using Rails console commands, which involves running Discourse.disable_readonly_mode with the Discourse::USER_READONLY_MODE_KEY argument. tgxworld confirms this works, while pfaffman notes the function’s requirement for an argument seems like a UX issue. tgxworld explains that Discourse.disable_readonly_mode isn’t a public API and the argument is needed to target specific read-only modes. The discussion also touches on potential causes like Redis failovers and the need for a more robust emergency solution, with riking suggesting an emergency_disable_readonly_mode function.
Hi all,
My site is suddenly in ‘read only’ mode, and I don’t know why.
chathamhouse.sandbaggernews.com
A friend helped me set up Discourse, but unfortunately he’s left town for a Linux conference in Seattle 
I’m trying to present this site to my professors tomorrow night. Really don’t know where to begin.
Thanks so much,
Stuck.
If you can ssh into the site host, try this :
./launcher enter app
rails c
Discourse.disable_readonly_mode
Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)
That did it. Thank you.
I had a client with this problem just now.
I don’t know how the site ended up in Read only mode.
I don’t know why disable_readonly_mode requires an argument.
These seem like bugs.
Is it still in read only mode? There is a way to figure out the cause of it by looking for the right Redis keys.
I don’t understand how disable_readonly_mode requiring an argument makes it a bug.
Maybe it’s a UX thing. 
it would just seem that such a function could be written such that it didn’t need an argument
How to check the redis keys? Oh. No I managed to get it out of read only with your help, so we can’t tell now?
And apparently it used to work without an argument.
It doesn’t need an argument by default 
Anyway, Discourse.disable_readonly_mode isn’t public API so what used to work might not always continue to work. The source code is the “source” of truth in this case.
Assuming you ran Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY) to get it out of read only mode, it was a user that enabled readonly mode.
Perhaps mere mortals don’t often need to do that.
So I have a similar issue. After getting through here (Inheriting discourse install - need some assistance - #13 by jerdog) I am attempting the Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY) but it keeps returning => true, is out of RO Mode for a second and then pops back in. I don’t have that key if I need to physically type it in… So stuck a bit
Did anybody manage to get really out of the stuck mode?
I’ve been seeing this for a couple of days now on our instances.
It might be that on our side it was triggered by a automatic failover within Redis.
Is there any key in Redis or Postgresql helping me to understand the problem?
To whom it may concern:
Still I don’t know why one of my containers obviously was not willing to perform. No log entry. No further indication.
Does Discourse follow this crazy “Have you tried to turn it on and off again”?
Hey, @tgxworld. I just got stuck on this problem for a while moving someone to a different server. Is there a reason that Discourse::USER_READONLY_MODE_KEY isn’t the default so that one doesn’t have to sometimes remember to add this argument?
Perhaps add an emergency_disable_readonly_mode that hits all redis keys?
This isn’t a public API and in our code base Discourse.enabled_readonly_mode(Discourse::READONLY_MODE_KEY) is used way more often.
Fair enough, but my question is still if there is a reason that the argument isn’t the default. Usually it’s not necessary, but in some cases (I guess mostly when you move a red only database to another server it is. And then one needs to remember to add Discourse::READONLY_MODE_KEY. Couldn that be the desk argument so that it’s never necessary for someone to include it?