Azurel
Silver Pleskian
- Server operating system version
- AlmaLinux 8.10
- Plesk version and microupdate number
- Plesk Obsidian 18.0.80#1
I ran into a serious issue while preparing an AlmaLinux 8 to AlmaLinux 9 upgrade using the official almalinux8to9 migration script. The script flagged some old packages as blockers for the upgrade. Removing the reported packages triggered a dependency chain reaction that took several core Plesk components down with it, effectively uninstalling my complete Plesk installation.
While investigating this, I found what looks like the actual root cause: Plesk apparently never removes old versions of its own modules. Every version ever installed via updates seems to just stay on the system indefinitely, side by side with the current one.
That's ~40 versions of a single module. And this is just one example. This looks like the real reason obsolete packages end up blocking major OS upgrades in the first place: if superseded versions are never cleaned up, the installed package base just keeps growing, and eventually something in that pile turns into a hard blocker and with the removal then cascading into core components, as happened to me.
My questions:
While investigating this, I found what looks like the actual root cause: Plesk apparently never removes old versions of its own modules. Every version ever installed via updates seems to just stay on the system indefinitely, side by side with the current one.
rpm -q --whatrequires luajit
no package requires luajit
rpm -q --whatrequires libc-client
no package requires libc-client
dnf remove luajit libc-client -y
Dependencies resolved.
================================================================================
Package
Arch Version Repository Size
================================================================================
Removing:
libc-client
x86_64 2007f-24.el8 @PLESK_18_0_28-thirdparty
1.5 M
luajit
x86_64 2.1.0-0.16beta3.el8 @PLESK_18_0_28-thirdparty
1.2 M
Removing dependent packages:
mod-security-v3
x86_64 3.0.16-2.redhat.8+p18.0.79.3+t260720.0455 @PLESK_18_0_79-dist 2.6 M
...... 100 lines later
sw-engine-cli-2.28
x86_64 2.28.0-1centos.8.200526.0923 @PLESK_18_0_28-dist 17 M
sw-engine-cli-2.29
x86_64 2.29.0-1centos.8.200720.1802 @PLESK_18_0_29-dist 17 M
sw-engine-cli-2.30
x86_64 2.30.1-1centos.8.200904.1939 @PLESK_18_0_30-dist 17 M
sw-engine-cli-2.31
x86_64 2.31.0-1centos.8.200921.1614 @PLESK_18_0_31-dist 17 M
sw-engine-cli-2.32
x86_64 2.32.0-1centos.8.201126.1926 @PLESK_18_0_32-dist 17 M
sw-engine-cli-2.33
x86_64 2.33.1-1centos.8.210121.1718 @PLESK_18_0_33-dist 17 M
sw-engine-cli-2.34
x86_64 2.34.2-1centos.8.210317.1718 @PLESK_18_0_34-dist 16 M
sw-engine-cli-3.35
x86_64 3.35.0-1centos.8.210401.0902 @PLESK_18_0_35-dist 17 M
sw-engine-cli-3.36
x86_64 3.36.0-1centos.8.210430.1630 @PLESK_18_0_36-dist 17 M
sw-engine-cli-3.37
x86_64 3.37.2-1centos.8.210707.1231 @PLESK_18_0_37-dist 17 M
sw-engine-cli-3.38
x86_64 3.38.0-1centos.8.210809.1933 @PLESK_18_0_38-dist 17 M
sw-engine-cli-3.39
x86_64 3.39.1-1centos.8.210924.1829 @PLESK_18_0_39-dist 17 M
sw-engine-cli-3.40
x86_64 3.40.1-1centos.8.211118.1957 @PLESK_18_0_40-dist 18 M
sw-engine-cli-3.41
x86_64 3.41.1-1centos.8.220111.1225 @PLESK_18_0_41-dist 18 M
sw-engine-cli-3.42
x86_64 3.42.1-0redhat.8.220228.1507 @PLESK_18_0_42-dist 18 M
sw-engine-cli-3.43
x86_64 3.43.2-0redhat.8.220331.1322 @PLESK_18_0_43-dist 18 M
sw-engine-cli-3.44
x86_64 3.44.0-0redhat.8.220421.1713 @PLESK_18_0_44-dist 18 M
sw-engine-cli-3.45
x86_64 3.45.0-0redhat.8.220603.0903 @PLESK_18_0_45-dist 18 M
sw-engine-cli-3.46
x86_64 3.46.0-0redhat.8.220728.1331 @PLESK_18_0_46-dist 18 M
sw-engine-cli-3.47
x86_64 3.47.2-0redhat.8.220920.1221 @PLESK_18_0_47-dist 18 M
sw-engine-cli-3.48
x86_64 3.48.0-0redhat.8.221010.0840 @PLESK_18_0_48-dist 18 M
sw-engine-cli-3.49
x86_64 3.49.0-0redhat.8.221130.1057 @PLESK_18_0_49-dist 18 M
sw-engine-cli-4.50
x86_64 4.50.0-0redhat.8.230115.1423 @PLESK_18_0_50-dist 18 M
sw-engine-cli-4.51
x86_64 4.51.0-0redhat.8.230222.0826 @PLESK_18_0_51-dist 18 M
sw-engine-cli-5.53
x86_64 5.53.2-0redhat.8.230612.1943 @PLESK_18_0_53-dist 20 M
sw-engine-cli-5.54
x86_64 5.54.1-0redhat.8.230707.0531 @PLESK_18_0_54-dist 20 M
sw-engine-cli-5.55
x86_64 5.55.1-0redhat.8.230817.1224 @PLESK_18_0_55-dist 20 M
sw-engine-cli-5.56
x86_64 5.56.1-0redhat.8.230929.1446 @PLESK_18_0_56-dist 18 M
sw-engine-cli-5.57
x86_64 5.57.1-0redhat.8.231107.1000 @PLESK_18_0_57-dist 18 M
sw-engine-cli-5.58
x86_64 5.58.2-0redhat.8.231229.1122 @PLESK_18_0_58-dist 18 M
sw-engine-cli-5.59
x86_64 5.59.2-0redhat.8.240130.1409 @PLESK_18_0_59-dist 18 M
sw-engine-cli-5.60
x86_64 5.60.1-0redhat.8.240318.0906 @PLESK_18_0_60-dist 18 M
sw-engine-cli-6.61
x86_64 6.61.1-0redhat.8.240426.1114 @PLESK_18_0_61-dist 18 M
sw-engine-cli-6.62
x86_64 6.62.1-0redhat.8.240612.0902 @PLESK_18_0_62-dist 18 M
sw-engine-cli-6.64
x86_64 6.64.1-0redhat.8.240830.0854 @PLESK_18_0_64-dist 18 M
sw-engine-cli-6.65
x86_64 6.65.1-0redhat.8.241101.1321 @PLESK_18_0_65-dist 18 M
sw-engine-cli-6.66
x86_64 6.66.2-0redhat.8.241126.0735 @PLESK_18_0_66-dist 18 M
sw-engine-cli-6.67
x86_64 6.67.2-0redhat.8.250114.0939 @PLESK_18_0_67-dist 18 M
sw-engine-cli-6.68
x86_64 6.68.1-0redhat.8.250217.0837 @PLESK_18_0_68-dist 18 M
...... more lines later
Transaction Summary
================================================================================
Remove 130 Packages
Freed space: 1.0 G
...... more lines later
Complete!
That's ~40 versions of a single module. And this is just one example. This looks like the real reason obsolete packages end up blocking major OS upgrades in the first place: if superseded versions are never cleaned up, the installed package base just keeps growing, and eventually something in that pile turns into a hard blocker and with the removal then cascading into core components, as happened to me.
My questions:
- Is this intentional kept for rollback purposes (for so many versions?), or is it an oversight?
- If intentional, is there a supported way to clean up old, unused module versions without risking a repeat of the dependency cascade above?
- Shouldn't superseded versions be removed automatically during regular updates instead of accumulating for years?