Docker installation doesn't start anymore


#22

When you say some time, how long do you mean?

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?

Thanks


#23

The longest I’ve seen is 5-10 minutes. No longer than that.

If it’s still doing it, you can get a shell in the cms-web container, kill the running PHP process and the webserver will start.

You can then look in to why the maintenance task is taking so long to run


#24

Ah, that would be useful.

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?

Thanks


#25

Run

docker ps

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.


#26

Thank you Alex!

Now to find out what is causing the maintenance task to take so long…


#27

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.


#28

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

Thank you so much for the help.


#29

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.


#30

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?


#31

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!