- Joined
- Dec 24, 2020
- Messages
- 45
- Reaction score
- 42
Hi,
I have been having major issues upgrading 3CX v18 systems to v20 on self-hosted Linux instances with 2 vCores and 4 Gb of RAM.
Reproduceable on every single instance: the upgrade process runs our of memory and fails (restore from snapshot required).
Monitoring the upgrade process in detail, I have nailed the culprit: fail2ban. Apparently, even if it is stopped, it restarts after some of the upgrades and hogs the memory causing the failure.
Initially, I tried adding fail2ban to the disable_monitoring_software function of the update.sh script. However, since upgrades restart any monitoring software that has been stopped, this doesn't work. The update.sh script would probably need to be called after every 'apt_command "upgrade"' in the update.sh script to ensure that restarted monitoring software is stopped again.
When fail2ban is disabled before starting the upgrade, everything works.
Hopefully, this feedback will help others having the same issue.
Best regards,
Gilles
I have been having major issues upgrading 3CX v18 systems to v20 on self-hosted Linux instances with 2 vCores and 4 Gb of RAM.
Reproduceable on every single instance: the upgrade process runs our of memory and fails (restore from snapshot required).
Monitoring the upgrade process in detail, I have nailed the culprit: fail2ban. Apparently, even if it is stopped, it restarts after some of the upgrades and hogs the memory causing the failure.
Initially, I tried adding fail2ban to the disable_monitoring_software function of the update.sh script. However, since upgrades restart any monitoring software that has been stopped, this doesn't work. The update.sh script would probably need to be called after every 'apt_command "upgrade"' in the update.sh script to ensure that restarted monitoring software is stopped again.
When fail2ban is disabled before starting the upgrade, everything works.
Hopefully, this feedback will help others having the same issue.
Best regards,
Gilles
