Since a couple weeks ago the web page gives the error page. So I tried to debug, shutting down all mastodon_X_1 docker containers and keeping up the live_X_1 containers. There seems to be a problem with localhost:3000 as mastodon_web_1 and live_web_1 both try to bind to it.
However, killing all mastodon_X_1 containers and using docker-compose up to bring the live_x_1 containers to life again and then rebooting gets everything the website online (full functionality i believe) again with mastodon_streaming_1 being unhealthy and live_streaming_1 and mastodon_web_1 not even alive.
The elasticsearch container is also always restarting due to a permission error but that exists outside of this I believe.
I’ve uncommented the elasticsearch portion other than that everything is the same
Could it be that you have 2 Docker installation of Mastodon running at the same time?
docker ps return? How have you determined that localhost:3000 is binding to multiple containers?
I’ve linked some terminal output. The thing that’s made me curious since the beginning has been the duplicate containers, but I assumed they were necessary and I believe they are in some way. Without the mastodon_X_1 dockers the live_X_1 ones don’t seem to function. But as you can see live_streaming_1 is not alive and mastodon_web_1 is also not alive. Yet, the instance currently functions.
When I first installed all containers would be alive and everything was functional.
localhost:3000 is used by the web_1 containers and localhost:4000 is being used by streaming_1 containers. These are the only containers causing me problems besides the elastic search.
There shouldn’t be any duplicate containers.
I would comment back ElasticSearch just to be sure that nothing from there is messing things up.
So, besides ElasticSearch you should only have 5 containers:
Do you get any errors returned in the container logs?
yeah there are some errors
mastodon_streaming_1 which is marked unhealthy has an error “relation “oauth_access_token” does not exist” repeated for maybe 50 lines.
whereas live_streaming_1 which is not alive has
info Starting worker 62573
info Worker 62573 now listening on 0.0.0.0:4000
ERR! Error: Redis connection to redis:6379 failed - connect ECONNREFUSED 172.20.0.2:6379
info Worker 62573 exiting, bye bye
mastodon_web_1 which is not alive is also putting out a lot of errors. this one’s log is a lot of jibberish and most of it pertains to “session_activations” and ActiveRecord:StatementInvalid
the live version is putting out seemingly normal logs.
both versions of redis seem to be the same
live_db_1 puts out a lot of normal log output i believe. the mastodon_db_1 version however is talking about “session_activations”. this is the same error over and over it seems.
“ERROR: relation “session_activations” does not exist at character 566”
mastodon_sidekiq_1 has another similar error as another container
“Error connecting to Redis on redis:6379 (Errno::ECONNREFUSED)”
this prints after printing ruby files and booting and it does this repeatedly
then I commented out elasticsearch in the compose yml and rebooted. the live_es container still got booted and the instance is now down again. the live web and streaming containers are dead.
Well, it sounds like a Redis connection error.
What are the Redis settings you have on the .env.production file?
that’s all that I have for redis
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.