Input AlmaLinux8to9 upgrade leaves Plesk in broken state with insufficient service checks and recovery guidance

[Azurel]

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.

 

[scsa20]

Never went through any kind of conversation but I can say that there's any number of reasons why something could fail, this is why it's always recommended that you have backups and a snapshot so you can always revert back on, it's even stated in the preparation that is' highly recommended that you create a snapshot before hand if all possible because anything could happen.

As for why it could fail, it could be that you're not on 8.9 (which was note tested on per the blockers) and if the plesk version is more then 5 releases behind the latest version (usually the script will prevent you but who knows).

If you have suggestions for how to harden it for collections and such, you can leave feedback by opening an issue on their github page where they check that more at GitHub - plesk/almalinux8to9: AlmaLinux 8 to 9 Conversion With Leapp

 

[Azurel]

Thanks, but I’m not sure how this post is relevant to the issue I described. I was running the latest AlmaLinux 8.10 with the latest Plesk version.

The post was specifically about what happens when something goes wrong during almalinux8to9. leapp worked fine and Almalinux was 9. Only plesk failed here to refresh. Plesk neither explains directly in the AlmaLinux8to9 documentation how to repair Plesk in such a situation, nor does plesk repair / the extension repair test necessarily detect all resulting problems.

For example, almalinux8to9 disabled services, those services were actually still required by Plesk and were not re-enabled. So even after re-install Plesk and running the repair tests, the system not detect this issue.

That was the actual issue I was trying to point out.