Docker for Windows: CMS is reset when I restart the host server

So you have two lots of the containers running - one set called xibo and one set called xibodocker.

My guess would be that your CMS install is actually in c:\xibo and not in c:\xibo\xibo-docker?

If so, to recover:

cd \xibo\xibo-docker
docker-compose down
cd \xibo
docker-compose stop
docker-compose start

assuming you didn’t use a different docker-compose file (eg cms_remote-mysql.yml or cms_custom-ports.yml).

Hi Alex,

Many thanks. I believe I have just the one instance running now. I still think I am having issues. The docs state:

Another good check is to make sure that shared/backup/db/latest.tar.gz

I assume this is my xibo shared directory. In mine this is empty

So that would be c:\xibo\shared\backup\db\latest.tar.gz

That file definitely doesn’t exist?

If not, did you follow the instructions and set the MYSQL_PASSWORD in config.env to an alpha-numeric string? Or did you put something in there with spaces, punctuation etc?

I stripped that machine bare and reinstalled Win 10 Pro. I re-installed everything fresh and I have a working system. However, nothing is in the shared/backup/db folder.

The mysql password is a simple 7 character ( everything will be in a VPN) alphanumeric.

It can take up to 24 hours before the first backup will be created in that directory. Please check back tomorrow and there should be a file there.

Again, no file. The machine rebooted again and lost all configuration again. It has to be something very simple I am missing.

The configuration being lost is expected.

It’s an issue with Docker on Windows. You need to restart the containers to have them reconnect properly.

So from the command prompt (for your specific installation):

cd \xibo\xibo-docker
docker-compose stop
docker-compose start

As to why you’re not getting a database file created, I’m not sure. If you can get me TeamViewer access, I’m happy to have a quick look for you. Please PM me the details. It will either need to be “now”, or tomorrow as I won’t be around much longer today.

Hi Alex, the CMS reset after a reboot (Win10) is exactly the reason I performed a new installation of Xbo using all the default settings (installation in c:\xibo instead of on a other drive). Xibo is up and running but I’ve got the same problem after a restart, all the settings are gone. I’ve tried the advised steps:
cd \xibo
docker-compose stop
docker-compose start

but this makes no diffferance, even the password is back to default.
When I check the library the data is still there (that’s a relieve). Do you know some other posibilities to get is back?
Kind regards, Ron

Please check that the C: drive is still shared for Docker. If you’ve changed a password for example, then it might not be.

You go to the Docker icon in the task bar, and then go in to the Docker Settings as you did when you set it up. Unshare and then reshare the C: drive, then do the down/up for the containers again.

Alex, thx for the reply. I’ve uses your advise but still the original CMS is not back. After bringing up de CMS I saw some warnings in the loggging and I’ve added this to this message. Maybe this will help to solve this and I can start building :smile:

cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: The InnoDB memory heap is disabled
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Memory barrier is not used
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Compressed tables use zlib 1.2.3
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Using Linux native AIO
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Using CPU crc32 instructions
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Initializing buffer pool, size = 128.0M
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Completed initialization of buffer pool
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Highest supported file format is Barracuda.
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: The log sequence numbers 3628586 and 3628586 in ibdata files do not match the log sequence number 3628596 in the ib_logfiles!
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Database was not shutdown normally!
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Starting crash recovery.
cms-db_1 | 2018-01-22 17:23:08 1 [Note] InnoDB: Reading tablespace information from the .ibd files…
cms-db_1 | 2018-01-22 17:23:09 1 [Note] InnoDB: Restoring possible half-written data pages
cms-db_1 | 2018-01-22 17:23:09 1 [Note] InnoDB: from the doublewrite buffer…
cms-db_1 | 2018-01-22 17:23:09 1 [Note] InnoDB: 128 rollback segment(s) are active.
cms-db_1 | 2018-01-22 17:23:09 1 [Note] InnoDB: Waiting for purge to start
cms-db_1 | 2018-01-22 17:23:09 1 [Note] InnoDB: 5.6.38 started; log sequence number 3628596
cms-db_1 | 2018-01-22 17:23:09 1 [Note] Server hostname (bind-address): ‘*’; port: 3306

Hi Alex, finally I performed docker-compose stop and docker-compose start and to my surprise everything is back. Ok, I’m happy but still curius what has happened?

I suspect the drive wasn’t correctly shared, or you changed a password that meant that the drive was no longer shared with Docker, and then your log shows a crash recovery in progress on the database, so again I suspect you needed to do a second restart once the drive was correctly shared to restore your data.

Sorry to resurrect this old thread, but…

@Alex May I suggest that you guys adjust the compose file to utilize mounts instead of volumes? It would mean that if the filesystem is not yet ready, the container will simply fail to start. When combined with a restart policy, it would make the containers more resilient to filesystem issues. The only difference is that you’d need the mount points in the ./shared directory to have been created in advance.

1 Like

Very happy to give that a go. If it’s that simple, I’ll be delighted. I posted about this on the Docker forums and basically got no response beyond “we know about this already” so well worth a go.

I had a go at this. I hope I’m missing something as it would be great to get this working, but I’ve tried the following for the MySQL container:

version: "2.1"

services:
    cms-db:
        image: mysql:5.6
        volumes:
            - mysql:/var/lib/mysql
        restart: always
        environment:
            - MYSQL_DATABASE=cms
            - MYSQL_USER=cms
            - MYSQL_RANDOM_ROOT_PASSWORD=yes
        mem_limit: 1g
        env_file: config.env

volumes:
  mysql:
    driver_opts:
      type: none
      device: /host_mnt/c/xibo-docker/shared/db
      o: bind

That works, but I can’t use a relative path inside the device line, so it means everyone would have to edit that line depending on which platform they’re running on.

Have I missed something?

Ah. Relative paths. Yes.

I know that you can specify a relative path by adding a dot to the front for configs and other uses. I’m in a VM running boot2docker locally so it’s hard for me to test, but try ./shared/db instead?

That was the very first thing I tried. It just tells me that the directory isn’t available. The only way it worked for me was with a full path.

Some people seem to struggle to set a mysql password in config.env. I don’t think we can expect everyone to enter in the correct path which will differ in format and content depending on which of the Docker versions they’re using unfortunately.

Totally get the user experience end. It’s unfortunate that relative paths do not work in that fashion. The only other thing that you might want to try is making the same edit, but change the version of the file to something much newer, like 3.4 to see if relative paths were added as a feature later. I know it seems like it shouldn’t matter, but Docker is pretty rigid about how compose files are interpreted sometimes.

If that doesn’t work, I’m tapped out.

Actually, I lied. It’s right in the docs

    volumes:
      - type: bind
        source: ./static
        target: /opt/app/static

Ditch global volumes section at the end and it should work!

Edit: Note this is the compose v3 reference.

Hi Alex,

I tried to follow instructions on this thread as I had the same problem (CMS was reset after a proposed update of Docker for Windows). I can still see my files in this folder C:\xibo\xibo-docker\shared\cms\library so I guess we should be able to get back everything.

I checked that my C: drive is still shared in docker UI
And I have an alpha numeric password in config.env

I tried to do :
cd \xibo\xibo-docker
docker-compose down
cd \xibo\xibo-docker
docker-compose stop
docker-compose start

and it gave me:
Starting cms-db … done
Starting cms-xmr … done
Starting cms-web … done
ERROR: No containers to start

And from there, I’m not sure how to start a container. (sorry it was hard to follow everything, I hope I haven’t missed the solution written somewhere else).

I tried to upload my docker-compose config but it wouldn’t let me post more than 2 links…

Thanks for your help!