The java/jetty monitor should use higher allowed limits by default, to avoid too aggressive self-healing procedures.

Sync both Hostmaster (before and after the upgrade) and Provision (before the upgrade) db_passwd to avoid issues with duplicate leftover grants.

Also, there is no point in using potentially dangerous vm.overcommit_memory=1 recommended by Redis, because we already tune Redis to use only 1/4 of RAM or less, while vm.overcommit_memory=1 may cause kernel OOM events killing processes when the parent system uses very aggressive resources mgmt.

This may cause extended downtime during unattended upgrades when there is new version released and the new NewRelic packages may simply hang the process for some weird reason, like probably because of not honoring the non-interactive mode and waiting forever for y/n response. We are avoiding this by uninstalling NewRelic completely before running system full-upgrade and then doing this again if later in the process newer version of PHP happened to be installed.

This is really silly to include the core "update" module as required and always enabled in any installation profile or feature, yet, some distros like Panopoly and deprecated Martplug does do that for unknown reasons, so disabling this module normally is impossible and forcing disable via Drush disables all other modules chained in the feature, which causes surprises like an empty homepage and other nice results.

Distros are usually build partially from the download on d.o, but often include extra contrib modules with dev releases, which could make BOA stable instances different, depending on the build or upgrade date. Furthermore, some distros are build from scratch with makefiles, also referencing contrib modules with dev releases and this is not only not so stable, but also extremely slow. We need to speed up things for stable BOA editions and make them as static as possible, where possible.

It was a workaround for some issues with Expiry/Purge modules, but we no longer use them.

This needs serious spring cleaning, but at least we should make sure that the service is restarted *after* the config is updated and before error checking procedure.