Hi, I have a multiserver setup with 5 Servers and yesterday, I've updated all my servers from stretch to buster. Everything went pretty smooth, I only had issues that the remote users in mariadb couldn't connect anymore. After adding them back with privileges, updating ISPConfig on all systems to .p3 went smooth. The Systemstatus for the master server is correct, it also shows buster, but all other servers are still at "version p2" and "need updates" and recognized als "stretch". I think something is preventing the system status from updating. What can I do? Everything should be green, but its not. Thanks!
P.S: what I've done so far: reinstalled ISPConfig on all servers (including master, using update.php), reconfigured permissions in master + reconfigured services, but unfortunately to no success. Even the uptime is showing "20 days", while I have rebooted yesterday.
See the instructions that I posted here yesterday: https://www.howtoforge.com/communit...ws-mysql-time_wait-on-master-and-slave.83838/ You should also find several other threads in the forum where debugging of master/slave connection issues is explained.
@till I don't have any connection issues. Slave -> master is working, only the status is not updating. There is also no stuck job in the queue
Ok. Then check the root crontab with: crontab -l to ensure that the cron.sh script is called once a minute.
Calling /usr/local/ispconfig/server/server.sh with debug mode (on all servers) results in: 25.02.2020-11:46 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 25.02.2020-11:46 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished.
@till 0 */8 * * * /usr/local/bin/mysqlbkup.sh 1>> /var/log/mysqlbkup.log 2>>/var/log/mysqlbkup-err.log 23 4 */2 * * /usr/bin/sa-update --no-gpg &> /dev/null @hourly sa-update --nogpg --channel spamassassin.heinlein-support.de && systemctl reload spamassassin @hourly sa-update && systemctl reload spamassassin * * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done * * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done And I also triggered cron.sh manually - status won't update. Also turning debug mode on off, I can see that everything gets set correctly. The Multiserver setup is working fine
Have you followed the ISPConfig Perfect Server Guide for Buster and verified you have all necessary packages installed and configurations done according to that manual? Manual for Stretch is different.
What I did from the Perfect Server Setup was only the part with MariaDB and PhpMyAdmin. PHP is also 7.3. Anything else was just updating the sources.list + apt update, upgrade, dist-upgrade. Edit: Just checked everything, nothing is missing. Cron working fine: tail -f /var/log/ispconfig/cron.log
Check the sys_cron table on the master and on the slaves, it contains a column next_run. If the next run date is far in the future (more than 24 hours), then you can truncate (empty) that table. ispconfig will rebuild it step by step for all internal cronjobs. Just be aware that thinks like backups will run again as well right after the table was emptied.
Perfect, that fixed it. Now it detects everything correct, but still telling me that there are updates available while there are 0. Is this stored somewhere special too? Anything beside that works perfect now, thank you. Since I've truncated the table, next_run is set to 13:15 for tomorrow, it was 0 o'clock before. Will it still use the settings I've set in ISPConfig (2am in the morning) or will it use the next_run value) Edit: its green now, so it also detected that there are no updates left.
Hi All, First of all many thanks for ISP Config Team for great work and commitment. Also many thanks to ISP Config community for support and sharing knowledge. I have multiserver setup with 5 servers and and I just upgraded all of them from Debian 10 to Debian 11. Upgrade goes smoothly but afterwards I found out that information in the Monitor tab are up to date only for the master server. Above posted information helped me out to solve this problem and I want to share some thoughts and few SQL commands for those who might want to use CLI. In my case all slave servers next_run date set in the past but also some of them where set as running into running table. So it was necessary to drop infomation in both tables for all slave servers. Here are SQL commands which are doing this tasks (select is only to display the table content) use dbispconfig; select * from sys_cron; update sys_cron set running = 0; update sys_cron set next_run = NULL; I guess it might be quite common case during OS upgrade in multiserver setup. Take care.
