ISPConfig feature request: cron jobs order direction

This is not a good idea. For example, when you disable Let's Encrypt and re-enable it, it would go the wrong way around. So the last action should always be done last.

It might be that we introduce this in the feature

 

Wait, so you have 4 million cronjobs?!

I think the best solution would be to spread your sites/cronjobs over separate servers...

 

Can you share some details about the cronjobs? I'm still wondering how you have so many on one server.

 

Ok, so I guess there is a misunderstanding here. the sys_datalog is not what is commonly referred to as cronjobs, cronjobs are in the cron table only. sys_datalog is the config transaction log, and config transactions have to be executed in order. If you would execute them out of order or in reverse order, then the system will fail for most actions. Example: Reversing the order for the creation of a DNS tone would result in DNS records to be added before the zone itself exists, this means you end up with a bunch of errors plus an empty zone at the end.

One solution might be to run multiple servers, e.g. if you have so many automated DNS transactions and you don't want to slow down transactions when adding a website or database, then you can achieve that by using a multiserver setup where dns nodes are separated from other nodes as each slave node in a multiserver system processes changes on it's own.

 

Do you use BIND with the normal file backend in ISPConfig? If yes, then you might try to modify it to remove the named zone check to speed things up, but you might have to add other checks then to avoid errors.

 

You can try to disable the zone check like this:

Edit the file /usr/local/ispconfig/server/plugin-available/bind_plugin.inc.php

comment out line 337 - 339:

Code:

$app->system->exec_safe('named-checkzone ? ?', $zone['origin'], $filename);
            $out = $app->system->last_exec_out();
            $return_status = $app->system->last_exec_retcode();

and add in that place:

Code:

$return_status = 0;

you might end up with some zone file loading errors in the syslog, but bind ignores such zones anyway as far as I know. So your log will contain some errors of files which would not be included in the bind config otherwise, but it should speed up things when not every change gets checked in this way.

 

another possibility might be to switch from file-based BIND setup to database-based powerdns setup. The powerdns plugin is not officially supported and documented, but I know that some ISP's use it and it might be faster when you have such a large amount of config changes to process as no files need to be written for the zones.