This install is running on Linux. It used to be a manual install using Apache/mysql. When i updated to 1.8.2, I swapped it over to Docker. When 1.8.10 came out, I updated it okay. It has always been fine and the CMS accessable.
When I got this issue the other day, we really needed to change some of the content on one of the displays. After trying lots of things, the only thing I could think of doing was reverting back to the 1.8.2 backup I made. This resulted in a working system and I was able to change the display I needed.
Yesterday morning I installed some more RAM in the server thinking that it might help the maintenance to run quicker, but since the server was turned on, if I run âdocker-compose logs cms-webâ it still says it is running maintenance and I get the proxy error if I try and access the CMS. I have come in today to find that it is still in the same state, should it take this long?
I am very new to Docker, I hadnât used it before I updated to 1.8.2. Would you be able to point me to somewhere that I can read up on how to get a shell, and then what to do to stop the running PHP process?
Find the container that has cms-web_1 in the name, then run
docker exec -ti example_cms-web_1 bash
substituting the correct container name. That will get you a shell inside the container. You can then use ps -aux to get a listing of all processes. There will be one php process. Note itâs process ID (PID).
kill -KILL 4
substituting the appropriate process ID.
exit
Will get your back out of the container, and then the container logs should show that Apache has started.
First thing Iâd check is your XMR private address setting. By default itâs hidden in a Docker install, but as this is a conversion from a standard installation, it may well be wrong.
For a Docker install, it should be:
tcp://cms-xmr:50001
Donât confuse this with the XMR public address which is different.
If you canât see the XMR private address in the CMS settings (Displays tab I think) then youâll need to update that directly in the database. To do so, connect to your MySQL container (see How can I run a SQL command when using a Docker Install?) and then run the following SQL:
UPDATE `setting` SET `value`='tcp://cms-xmr:50001', `userChange`=0, `userSee`=0 WHERE `setting`='XMR_ADDRESS';
Then go in to the CMS, go to the Settings page and click Save.
The XMR private address is accessible in settings and it was set to localhost, I have now set it to what it should be. I noticed that there are quite a few duplicate settings in the display tab (see attached image), Whitelist Load Balancers on the network tab and Resting Log Level / Elevate Log Until on the Troubleshooting tab
Hmm that looks like some of the upgrade steps have been run multiple times. You can safely delete duplicate entries from the setting table in the database, as long as you leave one of each with the intended values.
Thanks for that, I went through and deleted all of the duplicate settings, so that has solved that one.
Am I right in thinking that now, if I request a screenshot, it should do it straight away? It doesnât here, which makes me think that the XMR setup still isnât quite right. Are there any other tests I can do?
Just used this to resolve an issue upgrading to 2.0.3
using sudo docker ps -a, sudo docker exec -ti name_cms-web_1 bash, ps and in my case kill -KILL 61 for 1 instance of Apache that must have been hung up.
access to CMS restored, thanks!
