Facebook
Twitter
Azurel
Silver Pleskian
I'd like to share some feedback on the AlmaLinux 8 → 9 upgrade via the almalinux8to9 script and the subsequent Plesk recovery.
The leapp part of the upgrade completed successfully and the OS was fully upgraded to AlmaLinux 9. However, after the reboot Plesk itself was essentially unusable. My attempt to reinstall Plesk surfaced a string of additional problems: nginx and Apache not working, the firewall not active, and vhost errors referencing "SecRuleEngine" (all of which worked fine before the upgrade). During troubleshooting I eventually discovered that several services were simply not running after the upgrade — fail2ban, crond, and the logrotate timer among them. Nothing in the reinstall/repair process pointed this out; I found it by accident.
What I find problematic: the almalinux8to9 script itself identifies services like crond and fail2ban as Plesk-related, yet the Plesk installer/repair process doesn't seem to verify their state at all. Specifically:
- If fail2ban is configured for Plesk but not running, why isn't this flagged during install/repair?
- Same question for crond.service and logrotate.timer.
- Shouldn't the installer either enable required services automatically, or at least report them as missing prerequisites before continuing?
I understand a major OS version upgrade can cause unforeseen issues, and Plesk can't prevent all of them. But given that almalinux8to9 is an officially supported upgrade path, I'd expect much tighter integration between the upgrade process, Plesk's service checks, and the repair tooling — rather than leaving admins to discover broken services by trial and error. Without AI-assisted troubleshooting I likely wouldn't have found all of these issues myself.
My main request: please add a service/dependency sanity check to the Plesk repair and reinstallation process and repair-extension (at minimum for services the upgrade script itself identifies as Plesk-related), and document a clear procedure for repairing Plesk after a successful OS upgrade.
The leapp part of the upgrade completed successfully and the OS was fully upgraded to AlmaLinux 9. However, after the reboot Plesk itself was essentially unusable. My attempt to reinstall Plesk surfaced a string of additional problems: nginx and Apache not working, the firewall not active, and vhost errors referencing "SecRuleEngine" (all of which worked fine before the upgrade). During troubleshooting I eventually discovered that several services were simply not running after the upgrade — fail2ban, crond, and the logrotate timer among them. Nothing in the reinstall/repair process pointed this out; I found it by accident.
What I find problematic: the almalinux8to9 script itself identifies services like crond and fail2ban as Plesk-related, yet the Plesk installer/repair process doesn't seem to verify their state at all. Specifically:
- If fail2ban is configured for Plesk but not running, why isn't this flagged during install/repair?
- Same question for crond.service and logrotate.timer.
- Shouldn't the installer either enable required services automatically, or at least report them as missing prerequisites before continuing?
I understand a major OS version upgrade can cause unforeseen issues, and Plesk can't prevent all of them. But given that almalinux8to9 is an officially supported upgrade path, I'd expect much tighter integration between the upgrade process, Plesk's service checks, and the repair tooling — rather than leaving admins to discover broken services by trial and error. Without AI-assisted troubleshooting I likely wouldn't have found all of these issues myself.
My main request: please add a service/dependency sanity check to the Plesk repair and reinstallation process and repair-extension (at minimum for services the upgrade script itself identifies as Plesk-related), and document a clear procedure for repairing Plesk after a successful OS upgrade.
