SOLVED Changed WP URL From within WP -- Site Can't be Found
-
Hello,
I changed the URL from within the WP dashboard. What I did not realize is that this is done within the Cloudron app configuration. I tested changing it there on a 2nd WP instance and it worked fine.
However, the 1st WP instance, where I changed it incorrectly, is not reachable through the admin panel. I have the A record created at my domain registrar correctly. And I also tried to reapply a name change through Cloudron for this 1st WP instance (hoping it would overwrite the setting in the WP admin panel, but it is not taking. It is also not responding to trying to force the URL change through the wp.config.php file.
Do you have any idea how I can recover this instance? It appears that WP is stuck and has a conflict with Cloudron.
-
@Shaun-Snapp Usually, a restart of the app will "sync" up the site url inside WordPress and the one configured in Cloudron. You can restart from the Console section of the app.
When you say it is unreachable, do you mean you see a Cloudron 404 page (nginx) or the browser gives some DNS error?
-
@Shaun-Snapp Don't worry, in the worst of case, you can access the DB with a Remote SQL app and change the values yourself, I had to do that once in a multisite installation (which Cloudron doesn't support changing the domain of - yet). Let us know if restarting the app reconfigures the domain and if not, we'll go to next steps.
-
@Lonk Thanks. I tried the remove SQL approach, but failed.
I did restart the app. But I tried it again just to make sure I covered that base. But it did not bring it back. It is still not responding.
-
@girish I did see the 404 page before, but after restarting, and also changing the URL back to what it was through the Cloudron UI, I see the 502 Bad Gateway error.
-
@Shaun-Snapp Usually, if it's a 5xx error, you will see some error in the app logs. Console -> Logs. Anything interesting there?
-
@girish This is the information after the backup yesterday, and when the problem started.
Oct 05 23:00:04 backing up
Oct 05 23:00:04 217:M 06 Oct 06:00:04.479 * DB saved on disk
Oct 06 09:58:07 2020-10-06 16:58:07,653 WARN received SIGTERM indicating exit request
Oct 06 09:58:07 2020-10-06 16:58:07,653 INFO waiting for redis, redis-service to die
Oct 06 09:58:07 2020-10-06 16:58:07,654 INFO stopped: redis-service (terminated by SIGTERM)
Oct 06 09:58:07 217:signal-handler (1602003487) Received SIGTERM scheduling shutdown...
Oct 06 09:58:07 217:M 06 Oct 16:58:07.659 # User requested shutdown...
Oct 06 09:58:07 217:M 06 Oct 16:58:07.659 * Saving the final RDB snapshot before exiting.
Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 * DB saved on disk
Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 * Removing the pid file.
Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 # Redis is now ready to exit, bye bye...
Oct 06 09:58:07 2020-10-06 16:58:07,660 INFO stopped: redis (exit status 0)
Oct 06 10:01:10 Generating SSL certificate
Oct 06 10:01:10 Generating a RSA private key
Oct 06 10:01:10 ........+++++
Oct 06 10:01:10 ............+++++
Oct 06 10:01:10 writing new private key to '/run/redis.cloudron.key'
Oct 06 10:01:10 -----
Oct 06 10:01:10 Starting supervisor
Oct 06 10:01:10 2020-10-06 17:01:10,173 CRIT Supervisor running as root (no user in config file)
Oct 06 10:01:10 2020-10-06 17:01:10,173 INFO Included extra file "/etc/supervisor/conf.d/redis-service.conf" during parsing
Oct 06 10:01:10 2020-10-06 17:01:10,173 INFO Included extra file "/etc/supervisor/conf.d/redis.conf" during parsing
Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO RPC interface 'supervisor' initialized
Oct 06 10:01:10 2020-10-06 17:01:10,180 CRIT Server 'inet_http_server' running without any HTTP authentication checking
Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO RPC interface 'supervisor' initialized
Oct 06 10:01:10 2020-10-06 17:01:10,180 CRIT Server 'unix_http_server' running without any HTTP authentication checking
Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO supervisord started with pid 1
Oct 06 10:01:11 2020-10-06 17:01:11,184 INFO spawned: 'redis' with pid 15
Oct 06 10:01:11 2020-10-06 17:01:11,187 INFO spawned: 'redis-service' with pid 16
Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=15, just started
Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # Configuration loaded
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 * Running mode=standalone, port=6379.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # Server initialized
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.197 * DB loaded from disk: 0.000 seconds
Oct 06 10:01:11 15:M 06 Oct 17:01:11.197 * Ready to accept connections
Oct 06 10:01:11 Redis service endpoint listening on https://:::3000
Oct 06 10:01:12 2020-10-06 17:01:12,288 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Oct 06 10:01:12 2020-10-06 17:01:12,288 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) -
What's strange is that the app doesn't seem to be running at all since there is no health check going on. Usually otherwise there is a CloudronHealthCheck in the logs every 10 seconds. Is the app stopped or in repair mode by any chance?
@Shaun-Snapp Are you able to enable to enable remote access (Support -> Enable SSH) and reach out to me on support@cloudron.io ? I can take a look immediately.
-
My error. I had the site stuck in recovery mode. It is back up now.
I am back to normal. Thanks
