Multiserver setup with Debian 9 Stretch and ISPConfig 3.1.11. ISPConfig Panel keeps showing the red dot with one job, stuck since yesterday. I followed FAQ instructions and have already repaired the typos I made in hostname and fixed ispsrv* accounts in dbispconfig. Now I no longer get errors, but that job stays stuck. Clicking on that red dot shows popup: Code: The following changes are not yet populated to all servers: datalog_status_u_server: 1 ispconfig.log on master shows: Code: ke 14.3.2018 18.36.01 +0200 ke 14.3.2018 18.36.01 +0200 ke 14.3.2018 18.36.01 +0200 14.03.2018-18:36 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. ke 14.3.2018 18.36.01 +0200 14.03.2018-18:36 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock ke 14.3.2018 18.36.01 +0200 finished. On slave: Code: ke 14.3.2018 18.35.01 +0200 ke 14.3.2018 18.35.01 +0200 ke 14.3.2018 18.35.01 +0200 finished. ke 14.3.2018 18.35.01 +0200 /usr/bin/fail2ban-client ke 14.3.2018 18.35.01 +0200 /sbin/iptables ke 14.3.2018 18.35.01 +0200 /sbin/ip6tables ke 14.3.2018 18.36.01 +0200 ke 14.3.2018 18.36.01 +0200 ke 14.3.2018 18.36.01 +0200 finished. ke 14.3.2018 18.37.01 +0200 ke 14.3.2018 18.37.02 +0200 ke 14.3.2018 18.37.02 +0200 finished. ke 14.3.2018 18.38.01 +0200 ke 14.3.2018 18.38.01 +0200 ke 14.3.2018 18.38.01 +0200 finished. I can not see what else I could check. How can I see why that job queue stays stuck? Where can I check what that stuck item is trying to do?
Hi Taleman, This is the same as the issue I'm having as far as the content of the red dot goes heres mine The following changes are not yet populated to all servers: datalog_status_i_server_php: 3 datalog_status_u_server_php: 6
I'm beginning to suspect it is a glitch of some sort. There is that one job stuck in queue, but it does not halt the queue. If I change something in ISPConfig Panel, they show up in job queue for a while and then disappear.
And now it is gone. Good grief. I just tested by doing random changes to see they appear in job queue and soon disappear. I have no idea what that stuck job needed to get unstuck. Anyway, the issue resolved itself eventually, it seems.
It might be that the server.sh process died somehow and left a lock file which prevents that two processes run at the same time. If ISPConfig finds a lock file which is really old, then it assumes that something must have gone really wrong and it removes that lock in an attempt to solve the situation. That's what might have happened here and caused that 'self healing' effect.
