After I do that, should I just reboot the server a few times to force maintenance to run until the number pars down to normal?
I might submit that it seems like a small bit of a bug to require a region be filled purely in the sense that if I make a placeholder layout to remind me of something I want to do later. There is no way of knowing that is going to create these kind of log issues, the front end even seems to handle the situation fairly elegantly by giving the layout a gear icon and saying that it hasn’t been built yet. If an empty region is going to be this kind of issue the CMS should fight its existence a bit more vehemently would think.
Ok, so after going through and cleaning things up. We did a couple reboots and for the last one, we had a Daily Maintenance run time of 4s.
The Log query is now still high-ish but decidedly lower at 173024, with that hopefully decreasing over time as old entries continue to fall off the back.
My only remaining concern in this vein, and it may just be house cleaning, is that while the Daily Maintenance is listing as completed in 4s. The Status column still shows a gear set instead of a clock, and when I hover over the gear it says “PID: 0 (1969-12-31 18:00)”. I’ll also be keeping an eye on it to see if the next and last run columns update appropriately tonight.
Thank you for your time.
As of this morning;
Daily Maintenance still has the gears icon, its Last Run and its Next Run are both dated the 18th, which was the day of the last reboot.
All other Maintenance lines seem to be working as would be expected.
So that still implies it’s being run, and crashing for some reason, or taking longer than PHP will allow it to take.
I’d truncate the log table as a first step, and see if that resolves things.
Ok, I truncated the log table and rebooted the instance, my readout is now…
Daily Maintenance
Active: Check
Status: Gears
Next Run:2017-08-23 19:00
Run Now: X
Last Run: 2017-08-23 09:41
Last Status: Check
Last Duration: 0:00:02
I refreshed a couple times over the course of a few minutes to see if the gears would go away, but so far they remain.
OK. The gears will stay for 12 hours until that task times out. When that happens, it will try running it again.
Ok, I’ll circle back with you in the morning then.
The Daily Maintenance listing remains unchanged this morning.
Unchanged, dates are still from 8-23.
No change in Daily Maintenance behavior, dates still match the time of the last reboot. Everything else seems to be chugging along though.
What value do you have for your XMR Address setting in the Settings page of the CMS?
It should be
tcp://cms-xmr:50001
for a Docker-based installation. If it’s anything else, please change it to that.
The XMR Public Address should be
tcp://yourserver.domain.com:9505
Assuming the default ports have been left in operation.
We may be on the path to the solution here. In the CMS I went to Administration -> Settings, and search all the tabs. I found the XMR Public Address tab but not the XMR Address.
Our XMR Public Address is technically tcp://:9505, It’s only used on the internal network and systems ping against the server name fine so I assume this is ok, but it might be worth noting.
I also looked for XMR Private Address with no luck. Sorry if I’m being blind but I even went ahead and used Chrome’s page search.
If it is docker installation, then you should only need to set the public xmr address in CMS settings
as Alex has said it should be
tcp://yourserver.domain.com:9505 or tcp://your.ip.address:9505
Players need to be able to access this ip/domain on this port.
Private address should be tcp://cms-xmr:50001 by default and if it’s not visible in CMS settings then please check docker-compose.yml file there should be cms-xmr:50001 under ‘links’ section. If you haven’t changed it or if you’re not using any custom ports then that I believe it should be set to just that.
I’m sorry, I used brackets and messed up how that showed, our XMR Public address is tcp://ServerName:9505 So instead of name.domain.local, its just name. Our machines can ping based on name alone so is that fine or should I change it?
I’ve always left the docker-compose.yml file in its default state.
I can confirm that under “Services:->cms-web:->links:” I have
- cms-db:mysql
- cms-xmr:50001
And just to have it here the cms-xmr: entry is:
cms-xmr:
image: xibosignage/xibo-xmr:release_1.8.2
ports:
- "9505:9505"
restart: always
mem_limit: 256m
env_file: config.env
I believe that’s correct then (and indeed the default ports) ie 50001 for private and 9505 for public xmr address.
It’s relatively easy to test it, you can request a screenshot from player that should come back pretty much instantly, especially on local network or send some basic command.
Are the maintenance issues still persisting?
Is anything else not quite working for you?
If it’s a docker install originally, then we hide the private address as you never need to change it.
I’m wondering though if you have an incorrect value in there, causing your slow maintenance run.
You can check by connecting to MySQL, and running the following SQL:
SELECT setting, value from setting where setting like "XMR_%";
That should show you the XMR public and private address. The public address is inconsequential from the point of view of slow running Daily Maintenance task. If it’s wrong, the Players won’t be able to connect to XMR, but that’s not the issue we’re troubleshooting here. The XMR_ADDRESS is the one we’re concerned with. That should be set to
tcp://cms-xmr:50001
If it’s not, we have our culprit, and you can set it correctly by running the following SQL:
UPDATE setting set value="tcp://cms-xmr:50001" where setting="XMR_ADDRESS";
Instructions on connecting to MySQL are here:
If that isn’t the issue, then I think we’re at the stage where I need to see this first hand. I’ll need a copy of your data sent over (if you’re happy to do that) so I can recreate here and see what the issue is. If you want to do that, I can send over details of how to send your data to us.
Peter - Sending a screenshot request works pretty much immediately so we are good there I think.
Yes, the “Daily Maintenance” process still appears to be stuck for all intents and purposes.
To my knowledge, this is the only item sticking out at the moment, other than an issue with Tidy but Alex said that was a known bug you all are working on.
Alex - I ran the MySQL Command and it returned:
setting value
XMR_ADDRESS tcp://cms-xmr:50001
XMR_PUB_ADDRESS tcp://xibo:9505
So I guess we are at the sending data step. I’m fine with it, we don’t display anything particularly confidential.
Thank you for your time and assistance.