I have successfully installed xibo 1.8 to run with docker on my remote server, however after the initial database backup (shared/backup/db.latest.sql.gz) that was created shortly after I ran docker-compose up for the first time, it seems that no other backup was made afterwards (the file size of the database backup remains the same as well as the date modified, although I added a lot of content). If I understood correctly, by default the latest.sql.gz is updated with a cron job daily. Is there a log somewhere that might contain information on why the backup failed? Is there a way to recreate the backup through the cms, via a task perhaps? Thanks.
What OS is your server running?
If Windows, are you running Docker Toolbox or Docker for Windows?
Do you see your new files you uploaded in the shared/cms/library directory?
Hi alex! My server is running on Ubuntu 16.04.2. I can see all the files I upload inside the folder you mentioned. It’s just the database backup file that doesn’t seem to be updated. Even if I delete it, after a day or two, no new backup is created.
docker ps
will show you a list of running containers. In that list, look for the one that contains the name web. Here, that’s xibodocker_cms-web_1
Once you have that name (name_cms-web_1 in the example below), first run
docker logs name-web_1
Are any errors shown?
If not, run
docker exec -ti name_cms-web_1 bash
That will open a shell inside the container.
cat /etc/cron.daily/cms-db-backup
will show what is run when a backup is taken. Your MySQL password should be shown in that file. Check that that matches the one in config.env. If so, try manually running the backup
/etc/cron.daily/cms-db-backup
Is any error generated?
i had the same problem, and after performing these steps it is working and a new “latest.sql.gz” is saved.
No errors were shown at any point?
Can you check if cron is running correctly please? What does the following output from inside the container
ps aux | grep cron
cat /var/spool/anacron/cron.daily
I ran the logs command with no errors. I opened the cms-db-backup file, the code seemed normal, I verified that the password was correct. I ran the backup manually, it worked with no errors (it also worked when the file existed).
The ps aux | grep cron produced the following
root ___52 0.0 0.0 23656 _500 ? Ss Apr07 0:46 /usr/sbin/cron
root 30330 0.0 0.0 12788 1904 ? S+ 08:30 0:00 crontab -e
root 30331 0.0 0.0 _4448 _684 ? S+ 08:30 0:00 /bin/sh -c /usr/bin/sensible-editor /tmp/crontab.Bff1ns/crontab
root 30332 0.0 0.0 _4448 1644 ? S+ 08:30 0:00 /bin/sh /usr/bin/sensible-editor /tmp/crontab.Bff1nS/crontab
root 30345 0.0 0.1 26680 3100 ? S+ 08:30 0:00 editor /tmp/crontab.Bff1nS/crontab
root 30494 0.0 0.0 _8868 _764 ? S+ 08:52 0:00 grep --color=auto cron
the cat /var/spool/anacron/cron.daily produced 20170407 which is the date I initially ran the docker-compose up.
Any ideas?
OK I think we’re getting somewhere.
If you stop and start the container, is a new backup taken? (It will be 5-10 minutes after restart)
If so, please edit /etc/cron.d/anacron so it reads
# /etc/cron.d/anacron: crontab entries for the anacron package
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
30 7 * * * root anacron || :
I think what’s happening is cron is running, but anacron (which we’re using to ensure backups are taken even if the containers aren’t left running 24/7) is being run once, and then when cron tries to run it, it’s being invoked wrongly (via start -q).
If so, I can add a step to patch that in the build and release an updated container.
I had previously noticed that if I docker-compose down and up again a new backup is taken. Is this equivalent?
down/up is not the same as stop/start, but they do enough of the same things to be equivalent for the purposes of that test. If you can try the above please and then monitor for a couple of days that would be great.
I followed your instructions and edited /etc/cron.d/anacron. After a day, the backup was normally created at around 07:30am (container time). By the way, can I configure somehow the timezone of the web container on the docker-compose.yml to match my server timezone?
OK great thanks. I’ll get an updated container built to rectify this.
You can change the timezone by mapping your /etc/timezone file in to the container read only, but there shouldn’t be any need to.
You set the timezone your CMS lives in in the Xibo UI and that takes care of all of that for you. What timezone the container is running in (and it should be UTC really), is immaterial.
Those are built now.
Anyone else having the issue can correct it now by running:
docker-compose pull
docker-compose up -d (or whatever your normal up command is)
You should see it download new layers for the 1.8.1 CMS Web container, and then see a line similar to:
Recreating xibodocker_cms-web_1