In a IPSConfig multiserver setup (master/slave) jobs on slave server are no longer be executed. Database and mail replication are working fine, so does unison. I had configured backup to run on both servers at different times, but these backups are no longer executed on the slave. Also the slave health status is not actual (updates, services, ISPConfig version...) Big question mark in my eyes! Thanks for helping Ralph
try to connect from slave to master server with the mysql command by using the master database login details from ISPConfig config.inc.php file of the slave server.
I can connect to the master server with the above mentioned details. This user is seeing 16 tables in the ISPConfig schema. Is that ok?
That should be ok. Please take a look into the dbispconfig database on the slave, in the sys_cron table. Each record has a next_run date, these dates should be max 24 hours in the future.
These entries are ok, but the jobs are executed only on the master. As by the cluster setup for Debian 8.4 there is a master-master replication between the two servers and any change to the sys_cron table in the slave's dbispconfig database is replicated instantly to the master and the job is executed there. I am running Debian Buster on both machines. To get the chance to reconfigure the services, I updated to the git-stable repo and back to the stable 3.14p2 release. Each time on the slave first. Now I am back on the current stable but in the monitoring overview the slave still shows 3.1dev
Sorry, I meant you have to look into the dbispconfig2 database as that's the one which is used by the slave. The dbispconfig database that is replicated from master to slave is not used by the slave. There is a bug in current dev version which prevent cronjobs from being executed as it sets the next run time to January 2020, I'm quite sure that you have that issue too when you had dev branch on your servers. Take a look at
We have no fix for that yet, when the fix is available later today, then I'll post instructions on how to fix it.
That is no problem. After an UPDATE 'sys_cron' SET 'next_run' = 'actual date and time plus five minutes', the jobs are executed and next_run is set correctly. For me this is ok as a workaround.
Ok, you updated to stable, right? This fixes it as well in combination with setting the next_run date, the problem exists in dev only.