Latest.sql.gz not updating - older than 24 hours

I installed the Windows Docker version of Xibo 2.2.2 as a fresh install. All features worked fine. Within the same day I also attempted an upgrade to 2.3.0. I followed through the upgrade instructions at Upgrade Xibo for Docker Install | Xibo Digital Signage

After the upgrade the login page was stuck in the “undergoing maintenance” mode and would never complete.

I rolled back to my previous version and all worked fine again.

However, after several days I confirmed that my shared/backup/db/latest.sql.gz file was not getting updated, indicating a potential problem.

My troubleshooting steps, so far…

Determined web container name:

docker ps

Checked if there are any errors:

docker logs xibo_cms-web_1

Notable errors listed:

We will upgrade it, take a backup
mysqldump: Got error: 1146: “Table ‘cms.scheduleexclusions’ doesn’t exist” when using LOCK TABLES
Running database migrations

Opened a shell inside the container:

docker exec -ti xibo_cms-web_1 bash

Tried to manually run a SQL backup:

mysqldump -u cms -h mysql -p cms > /var/www/cms/library/temp/backup.sql

Saw this error:

mysqldump: Got error: 1146: “Table ‘cms.scheduleexclusions’ doesn’t exist” when using LOCK TABLES

Checked the SQL database:

mysqldump -u cms -h mysql -p cms

Partial results:

cms.resolution OK
cms.saved_report OK
cms.schedule OK
cms.scheduleexclusions
Error : Table ‘cms.scheduleexclusions’ doesn’t exist
status : Operation failed
cms.schedulereminder OK
cms.session OK

Tried running a repair:

mysqlcheck -u cms -h mysql -p cms -r

It appears it won’t work:

cms.saved_report
note : The storage engine for the table doesn’t support repair
cms.schedule
note : The storage engine for the table doesn’t support repair
cms.scheduleexclusions
Error : Table ‘cms.scheduleexclusions’ doesn’t exist
status : Operation failed
cms.schedulereminder
note : The storage engine for the table doesn’t support repair
cms.session
note : The storage engine for the table doesn’t support repair

I also looked at the docker logs:

docker-compose logs

Most everything looks good until this section at the end:

cms-web_1 | Starting cron
cms-web_1 | Starting webserver
cms-web_1 | AH00558: httpd: Could not reliably determine the server’s fully qualified domain name, using 172.21.0.5. Set the ‘ServerName’ directive globally to suppress this message
cms-db_1 | 2020-02-26 15:44:51+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.47-1debian9 started.
cms-db_1 | 2020-02-26 15:44:56+00:00 [Note] [Entrypoint]: Switching to dedicated user ‘mysql’
cms-db_1 | 2020-02-26 15:44:56+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.47-1debian9 started.
cms-db_1 | 2020-02-26 15:44:57 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
cms-db_1 | 2020-02-26 15:44:57 0 [Note] mysqld (mysqld 5.6.47) starting as process 1 …
cms-db_1 | 2020-02-26 15:44:57 1 [Note] Plugin ‘FEDERATED’ is disabled.
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Using atomics to ref count buffer pool pages
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: The InnoDB memory heap is disabled
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Memory barrier is not used
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Compressed tables use zlib 1.2.11
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Using Linux native AIO
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Using CPU crc32 instructions
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Initializing buffer pool, size = 128.0M
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Completed initialization of buffer pool
cms-db_1 | 2020-02-26 15:44:57 1 [Note] InnoDB: Highest supported file format is Barracuda.
cms-db_1 | 2020-02-26 15:44:58 1 [Note] InnoDB: 128 rollback segment(s) are active.
cms-db_1 | 2020-02-26 15:44:58 1 [Note] InnoDB: Waiting for purge to start
cms-db_1 | 2020-02-26 15:44:58 1 [Note] InnoDB: 5.6.47 started; log sequence number 51259095
cms-db_1 | 2020-02-26 15:44:58 1 [Note] RSA private key file not found: /var/lib/mysql//private_key.pem. Some authentication plugins will not work.
cms-db_1 | 2020-02-26 15:44:58 1 [Note] RSA public key file not found: /var/lib/mysql//public_key.pem. Some authentication plugins will not work.
cms-db_1 | 2020-02-26 15:44:58 1 [Note] Server hostname (bind-address): ‘*’; port: 3306
cms-db_1 | 2020-02-26 15:44:58 1 [Note] IPv6 is available.
cms-db_1 | 2020-02-26 15:44:58 1 [Note] - ‘::’ resolves to ‘::’;
cms-db_1 | 2020-02-26 15:44:58 1 [Note] Server socket created on IP: ‘::’.
cms-db_1 | 2020-02-26 15:44:58 1 [Warning] Insecure configuration for --pid-file: Location ‘/var/run/mysqld’ in the path is accessible to all OS users. Consider choosing a different directory.
cms-db_1 | 2020-02-26 15:44:58 1 [Warning] ‘proxies_priv’ entry ‘@ root@245b6ccc062b’ ignored in --skip-name-resolve mode.
cms-db_1 | 2020-02-26 15:44:58 1 [Note] Event Scheduler: Loaded 0 events
cms-db_1 | 2020-02-26 15:44:58 1 [Note] mysqld: ready for connections.
cms-db_1 | Version: ‘5.6.47’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 MySQL Community Server (GPL)
cms-db_1 | 2020-02-26 15:54:15 1 [Warning] InnoDB: Cannot open table cms/scheduleexclusions from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
cms-db_1 | 2020-02-26 16:00:01 1 [Warning] InnoDB: Cannot open table cms/scheduleexclusions from the internal data dictionary of InnoDB though the .frm file for the table exists.
cms-db_1 | 2020-02-26 16:13:17 1 [Warning] InnoDB: Cannot open table cms/scheduleexclusions from the internal data dictionary of InnoDB though the .frm file for the table exists.
cms-db_1 | 2020-02-26 16:15:01 1 [Warning] InnoDB: Cannot open table cms/scheduleexclusions from the internal data dictionary of InnoDB though the .frm file for the table exists.
cms-db_1 | 2020-02-26 16:16:32 1 [Warning] InnoDB: Cannot open table cms/scheduleexclusions from the internal data dictionary of InnoDB though the .frm file for the table exists.
cms-db_1 | 2020-02-26 16:30:01 1 [Warning] InnoDB: Cannot open table cms/scheduleexclusions from the internal data dictionary of InnoDB though the .frm file for the table exists.

I’m not sure if I should drop the table and try to recreate it empty maybe? I’m running my rolled back version of 2.2.2 just fine at the moment. Newly uploaded media appears in the “shared” folder as it should, but I’m not able to upgrade at this point. Thanks for looking!

backup the shared folder…I will copy that into a different folder then unzip the 2.3.0 in that folder that contains the xibo cms example… /opt/your-folder…

do not try to copy the content…unzip the downloaded 2.3.0 zip file into the cms base folder and try

Thanks for the feedback, but I’m not completely understanding what you mean for me to do. I’ve done this:

docker-compose stop

Backed up the shared folder. In my case, c:\xibo

Unzipped contents of 2.3.0 install into c:\xibo, overwriting existing files.

docker-compose down

docker-compose up -d

Navigate to http://localhost in browser:

image

docker-compose logs

docker logs xibo_cms-web_1

I ended up just exporting my layouts and datasets, blowing everything away, and installing 2.3.0 fresh. Re-importing the layouts, configuring my schedule, and making a few other settings changes only took a few minutes. Thanks for the help.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.