We have a master with several slave servers, all running 3.2.11p1. there are 28 changes pending but the jobqueue is empty. In the database, the updated indicates 85360 (which matches the highest sys_datalog) for all but one DNS server, which indicates 85264. What's showing for the updates is "datalog_status_u_client: 28". I tried running server.sh on both the master and the DNS server. when i ran the server.sh, I received the following error: PHP Warning: Undefined variable $state_out in /usr/local/ispconfig/server/lib/classes/plugins.inc.php on line 173 All other servers are up-to date and do not throw the error if server.sh is run. I have not changed the database entries, assuming the server.sh error should be addressed first. While I've looked for other posts, I've not found any that address the issue. Any suggestions?
That's not an error. It's just a warning. You can ignore that. Such warnings happen because PHP 8.x is way stricter when it comes to variable checking.
Thanks, Till. Why don't other servers throw the error? All are running php8.x? Any idea how to resolve the 28 changes and the different Updated value on the sever? I'm assuming they are related, but not sure if incrementing the Updated value on the NS server will resolve it. I'm out of my league here, so would appreciate any recommendations.
There is no error thrown in the output you posted. If it were an error, it would be named Error, not Warning. A Warning hints to developers where to improve the code, a Warning does not mean that there is a malfunction. Whether this warning is shown or not depends on the current code flow and the information that is processed by the script at that time. Regarding your initial problem, do you maybe have a server listed under system > server services that is set to inactive?
All servers are active. Don't know if this is relative, but we had 4 DNS servers (two each in two different locations for redundancy) with 3 as mirrors of the master. We recently changed to BIND master/slave with changes transferred between the master and 3 slaves. All works fine regarding transfers. I mention this because the master is the one that has the incorrect value in the Updated field. The reconfiguration from mirror to transfer is the only changes made to the server, other than updating with new releases. I'm not finding anything in any log files, but not sure what to look for. Any recommendations?
Please run the SQL query I posted here: https://forum.howtoforge.com/thread...nterface-reports-not-populated-changes.92186/ on the master, e.g., with phpmyadmin, and post the result. This helps to find out which server and/or which kind of record is causing the issue.
Ok, so these are the records that get distributed to all systems. You can just increase the counter for the master to fix this for now. I'll have to check in the code how this can happen. Might be that the master ignores the 0 records as it has the data in its db already and unless there is another change for the master, then the ID might not get incremented.
So you still have the blinking red dot in the upper menu and all updated columns are at the value of max datalog_id ?
Yes, to the red dot. the master has an Updated value of 85362 - that's what I updated to from 85361. The NS master server still shows 85264. All other servers show 85361.
datalog_status_u_client: 28 Delete DNS record: 1 Create DNS record: 1 Update DNS record: 1 Update DNS zone: 2
I just modified a DNS record, and the number of open items has dropped back to 28, the DNS entries are gone and the DNS change has been pushed to all servers.
So your NS server has likely pending changes when its updated column stays behind. any errors when running server.sh on the ns server after enabling debug mode?
server.sh result: PHP Warning: Undefined variable $state_out in /usr/local/ispconfig/server/lib/classes/plugins.inc.php on line 173 20.04.2024-13:20 - DEBUG [server:217] - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished server.php. Earlier, relating to the stuck updates, you mentioned: Ok, so these are the records that get distributed to all systems. You can just increase the counter for the master to fix this for now. I'll have to check in the code how this can happen. Might be that the master ignores the 0 records as it has the data in its db already and unless there is another change for the master, then the ID might not get incremented.That was based on a SQL query that returned: Output: cnt server_id 28 0 Checking the Updated field on all servers is a mess. The CP master shows a value of 85361. The DNS master is 85366. All other servers (7) indicate 85361. The last id in sys_datalog is 85366.
The values can differ; this does not always indicate a problem. The updated value is the last relevant record for that server, so it depends on when the server got a record that is either specifically for him or a global (server_id = 0).