Issue Older packages not being cleaned up

[slishy]

Server operating system version

CentOS 7.9

Plesk version and microupdate number

18.0.43.1

I'm starting to notice Plesk is not keen on removing older packages it no longer needs after you have upgraded a few versions (but still flags them as dependencies).
Doing an autoremove does not reveal these packages. Example:

# yum list installed | grep sw-engine
sw-engine.x86_64              3.43.2-1centos.7.220331.1322   @PLESK_18_0_43-dist
sw-engine-cli-2.21.x86_64     2.21.0-centos7.201702161518    @PLESK_17_5_3-dist
sw-engine-cli-2.24.x86_64     2.24.11-0centos.7.181127.1152  @PLESK_17_8_11-dist
sw-engine-cli-2.25.x86_64     2.25.5-1centos.7.190305.1554   @PLESK_17_9_12-dist
sw-engine-cli-2.26.x86_64     2.26.2-1centos.7.190627.1531   @PLESK_18_0_16-dist
sw-engine-cli-2.27.x86_64     2.27.7-1centos.7.200420.1017   @PLESK_18_0_27-dist
sw-engine-cli-2.29.x86_64     2.29.0-1centos.7.200720.1803   @PLESK_18_0_29-dist
sw-engine-cli-2.30.x86_64     2.30.1-1centos.7.200904.1939   @PLESK_18_0_30-dist
sw-engine-cli-2.31.x86_64     2.31.0-1centos.7.200921.1614   @PLESK_18_0_31-dist
sw-engine-cli-2.32.x86_64     2.32.0-1centos.7.201126.1926   @PLESK_18_0_32-dist
sw-engine-cli-2.33.x86_64     2.33.1-1centos.7.210121.1721   @PLESK_18_0_33-dist
sw-engine-cli-2.34.x86_64     2.34.2-1centos.7.210317.1720   @PLESK_18_0_34-dist
sw-engine-cli-3.39.x86_64     3.39.1-1centos.7.210924.1832   @PLESK_18_0_39-dist
sw-engine-cli-3.40.x86_64     3.40.1-1centos.7.211118.1959   @PLESK_18_0_40-dist
sw-engine-cli-3.41.x86_64     3.41.1-1centos.7.220111.1225   @PLESK_18_0_41-dist
sw-engine-cli-3.42.x86_64     3.42.1-1centos.7.220228.1507   @PLESK_18_0_42-dist
sw-engine-cli-3.43.x86_64     3.43.2-1centos.7.220331.1322   @PLESK_18_0_43-dist

# yum list installed | grep bootstrapper
pp17.5.3-bootstrapper.x86_64  17.5.3-cos7.build1705170317.16 @PLESK_17_5_3-dist
pp17.8.11-bootstrapper.x86_64 17.8.11-cos7.build1708180920.15
pp17.8.9-bootstrapper.x86_64  17.8.9-cos7.build1708180108.17 @PLESK_17_8_9-dist
pp17.9.11-bootstrapper.x86_64 17.9.11-1centos.7.190207.1653  @PLESK_17_9_11-dist
pp17.9.12-bootstrapper.x86_64 17.9.12-1centos.7.190305.1612  @PLESK_17_9_12-dist
pp17.9.13-bootstrapper.x86_64 17.9.13-1centos.7.190403.1351  @PLESK_17_9_13-dist
pp18.0.14-bootstrapper.x86_64 18.0-2.centos.7+p18.0.14.0+t190430.1351
pp18.0.15-bootstrapper.x86_64 18.0-2.centos.7+p18.0.15.1+t190619.1728
pp18.0.16-bootstrapper.x86_64 18.0-2.centos.7+p18.0.16.0+t190628.1517
pp18.0.17-bootstrapper.x86_64 18.0-2.centos.7+p18.0.17.0+t190725.1940
pp18.0.19-bootstrapper.x86_64 18.0-2.centos.7+p18.0.19.3+t191002.1251
pp18.0.20-bootstrapper.x86_64 18.0-2.centos.7+p18.0.20.2+t191101.1317
pp18.0.21-bootstrapper.x86_64 18.0-2.centos.7+p18.0.21.5+t191219.2005
pp18.0.24-bootstrapper.x86_64 18.0-2.centos.7+p18.0.24.0+t200213.1546
pp18.0.25-bootstrapper.x86_64 18.0-2.centos.7+p18.0.25.2+t200325.1928
pp18.0.26-bootstrapper.x86_64 18.0-2.centos.7+p18.0.26.0+t200410.1427
pp18.0.27-bootstrapper.x86_64 18.0-2.centos.7+p18.0.27.1+t200522.1215
pp18.0.29-bootstrapper.x86_64 18.0-2.centos.7+p18.0.29.3+t200825.2156
pp18.0.30-bootstrapper.x86_64 18.0-2.centos.7+p18.0.30.2+t200930.1355
pp18.0.31-bootstrapper.x86_64 18.0-2.centos.7+p18.0.31.3+t201209.0155
pp18.0.32-bootstrapper.x86_64 18.0-2.centos.7+p18.0.32.2+t201217.1925
pp18.0.33-bootstrapper.x86_64 18.0-2.centos.7+p18.0.33.1+t210225.1402
pp18.0.34-bootstrapper.x86_64 18.0-2.centos.7+p18.0.34.2+t210325.1052
pp18.0.39-bootstrapper.x86_64 18.0-2.centos.7+p18.0.39.2+t211117.1817
pp18.0.40-bootstrapper.x86_64 18.0-2.centos.7+p18.0.40.3+t220116.0005
pp18.0.41-bootstrapper.x86_64 18.0-2.centos.7+p18.0.41.1+t220207.2342
pp18.0.42-bootstrapper.x86_64 18.0-2.centos.7+p18.0.42.1+t220314.1713
pp18.0.43-bootstrapper.x86_64 18.0-2.centos.7+p18.0.43.1+t220414.1850

I would like to know if it is safe to remove older versions.

 

[slishy]

Bump.

 

[Hangover2]

We have the same issue on our servers. There seems to be no real cleanup. We have servers that came originally from Debian 10 and are now on Debian 12. Because of those dependencies we still have old packages of Debian 10 and 11 on the system. To check and remove those packages in aptitude via " Obsolete and Locally Created Packages" is quite time consuming.

Is there a better way to clean this mess up on Plesk servers?

 

[Kaspar@Plesk]

I've just learned that after a Plesk update sw-engine-cli-* and pp*-bootstrapper packages are indeed not cleaned up. We're aware of this. It safe to remove those packages manually if the upgrade completed successfully.

However packages left after dist-upgrade might indicate an issue (or be left unintentionally).

 

[Hangover2]

We had nearly 150 Debian 10 packages left after upgrading from Debian 10 to 11. All dependencies were connected in some way to Plesk packages. Originally this came to our attention because some dependency warnings were thrown in the upgrade process.

You can check your Debian systems to find the old packages with the following commands:

apt list --installed | grep debian.10
apt list --installed | grep deb10
apt list --installed | grep debian10

Then you can remove them step by step with e.g. aptitude. Be carful to purge only the old Debian 10 packages when you are resolving dependency conflicts. Also check that all Plesk sources are in place (e.g. plesk-ext-docker.list, plesk-ext-grafana.list, [...]). We had one system where plesk-ext-docker.list was missing (even though Docker was installed) and the "plesk repair" command did not check that. So the system was still using the old Debian 10 docker libraries inside Debian 11.

 

[learning_curve]

I've just learned that after a Plesk update sw-engine-cli-* and pp*-bootstrapper packages are indeed not cleaned up. We're aware of this. It safe to remove those packages manually if the upgrade completed successfully.

However packages left after dist-upgrade might indicate an issue (or be left unintentionally).

Never a dull moment here in Plesksville.

Acting only on one of our servers (to test this first) & only on the specific items shown in the above post, removing 'those packages manually' turns out to be not as straightforward as it might first appear... In our case, once those packages are removed, there is no detrimental effect whatsoever, on Plesk itself / the functionality of any of the hosted sites / any mail services etc, so this is not a mission critical situation & we didn't need to revert back to any previous server snapshots. However...

Once the above package removals are complete, there then follows a succession of warnings that the 'files list file' for said packages is 'missing'.
Some of the relevant data (the asumptions part of the warnings is correct, but why do we need this config check for removed packages anyway?)

dpkg: warning: files list file for package 'pp18.0.29-bootstrapper' missing; assuming package has no files currently installed

dpkg: warning: files list file for package 'sw-engine-cli-3.36' missing; assuming package has no files currently installed

These warnings are repeated for all of the removed packages (not just for these two examples) and are shown within many different CLI actions.

Then, we have this warning within the Plesk Panel itself:

Information on some packages might not be actual: inconsistencies were detected in the system's package manager database. Please resolve this issue manually.

There's an existing Plesk page that deals with this warning HERE
However, the Resolution on that page is to re-install the packages, which in this case, is obviously not the desired "fix"

We didn't expect Plesk Repair to be able to resolve these issues. Within Plesk Repair, there are in fact NO errors or warnings anywhere at all on this server / Plesk installation, apart from, those same 'missing' warnings as have already been provided above, despite the inital impression, that these were permission related errors. These 'missing' warnings become visible via plesk repair all -n followed by plesk repair fs -verbose (see below) but are always followed by the expected exit status 1 and as expected, Plesk Repair cannot repair any of these specific warnings.

Checking Linux system files

There are incorrect permissions on some items: /var/log/plesk ..... [ERROR]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

There are incorrect permissions on some items: /opt/psa/PMM/tmp ... [ERROR]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

There are incorrect permissions on some items:
/opt/psa/PMM/rsessions ............................................ [ERROR]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

There are incorrect permissions on some items: /var/log/plesk/PMM . [ERROR]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

Can you advise on how we can supress all of these superfluous warnings please @Kaspar@Plesk aka 'tidy up' these two package removals?

 

[Hangover2]

@learning_curve We did not experience such problems but we did only uninstall packages from the previous OS. The "old/obsolete" packages from the current OS are still in place.

 

[Kaspar@Plesk]

@learning_curve sorry to hear that happend. Let me see if I can find some more information on removing "those" packages.

 

[learning_curve]

@learning_curve We did not experience such problems but we did only uninstall packages from the previous OS. The "old/obsolete" packages from the current OS are still in place.

That might be a factor... but see the last message from @Kaspar@Plesk above aka we'll need to wait and see once the full removal process is known.
To be fair, it's just warnings, not errors, so it's not top of anybody's urgent inbox.

There's "old/obsolete" Plesk Packages, which is all that we were focused on in previous post and then there's "old/obsolete" Ubuntu packages, which, just like ourselves, we haven't processed - so far. We have identified them ( via ~# deborphan and/or ~# aptitude search '?obsolete') However, those search results do include some Plesk files too.... hence, so far, we've only processed the specific Plesk files that were identified by @Kaspar@Plesk in this thread.

What's become apparant (after participating in this thread) is, what you metioned @Hangover2 "...There seems to be no real cleanup" (sic) process from Plesk.
Does this need a Plesk suggestion submision? Perhaps @Kaspar@Plesk can confirm?
It's a big ask, if so, as this should be part & parcel of each & every Plesk upgrade, by default, really.

 

[Kaspar@Plesk]

Does this need a Plesk suggestion submision? Perhaps @Kaspar@Plesk can confirm?
It's a big ask, if so, as this should be part & parcel of each & every Plesk upgrade, by default, really.

Sure. We are aware that older packages aren't cleaned up. From what I understand it's more complicated that one would think to automate this in the upgrade process. But your are definitely welcome to add as a suggestion on our UserVoice. If it's gains some traction it be given a higher priority, but would not expected any changes soon.

Still looking in to your previous question @learning_curve, I wanted to react on your question in the mean time.

 

[Kaspar@Plesk]

@learning_curve just to be sure, how did remove the older packages?

 

[learning_curve]

@learning_curve just to be sure, how did remove the older packages?

It's not possible via Plesk Panel (unless we missed it...) but via CLI with ~# locate [package] and then ~# rm -rf [package] and/or with ~# dpkg -r [package]
Plesk may advise better methods, we're guessing...

 

[learning_curve]

@Kaspar@Plesk FWIW these do appear to only be warnings, generated as a result of any resultant database and/or possible dependency inaccuracies / false record sets etc (because of the actual file removals). It's now known that there's no actual 'cleanup' process that's invoked after any Obsidian Upgrades / New Releases. So, if said 'cleanup' process was never part of the original design brief / intent / specification etc, then in fairness, this is why they are now occurring by surprise and this is why they may take a little extra thought, to correct. Happy to try any suggestions (against one package name at a time) & post the results.

 

[Kaspar@Plesk]

It's not possible via Plesk Panel (unless we missed it...) but via CLI with ~# locate [package] and then ~# rm -rf [package] and/or with ~# dpkg -r [package]
Plesk may advise better methods, we're guessing...

That would explain the issues you're having. Removing package files manually can lead to issues, as you've already discovered.

The recommended method to remove unwanted packages is to use the OS package manager. For Ubuntu the appropriate command would be apt remove --purge <package name>

 

[learning_curve]

That would explain the issues you're having. Removing package files manually can lead to issues, as you've already discovered.

The recommended method to remove unwanted packages is to use the OS package manager. For Ubuntu the appropriate command would be apt remove --purge <package name>

Ahhh yes, that's the command we use (when required) on all Ubuntu Packages, but had wrongly assumed, that Plesk was package managed, independently outside of that. Our own, basic school boy error then... this explains why we couldn't find any references within Plesk as to what we'd assumed and this also negates post #13 in this thread.

Okay, well that was easy to correct and all those warnings have obviously now ceased. Thanks @Kaspar@Plesk

 

[learning_curve]

Seeing as we're on a Plesk 'clean up' thread
Could you comment on the Plesk related items that we've extracted, from the now updated deborphan (orphaned package finder) search results:

We've used deborphan here, with a modified output, then filtered the results, to only include those with Plesk in the package title. These are all orphaned packages within the deborphan default search area (i.e. within the libs, oldlibs and introspection sections only) and they are installed packages that name the packages that depend on them (or not, as is the case with all of these and/or their depenencies only exist within these orphaned packages anyway).

~# deborphan -d --show-deps
~
plesk-libboost-1.65

plesk-libboost-chrono1.65

plesk-libboost-date-time1.65

plesk-libboost-filesystem1.65

plesk-libboost-iostreams1.65

plesk-libboost-locale1.65

plesk-libboost-program-options1.65

plesk-libboost-regex1.65

plesk-libboost-serialization1.65

plesk-libboost-system1.65

plesk-libboost-thread1.65



plesk-libboost-1.74

plesk-libboost-chrono1.74

plesk-libboost-date-time1.74

plesk-libboost-filesystem1.74

plesk-libboost-iostreams1.74

plesk-libboost-locale1.74

plesk-libboost-program-options1.74

plesk-libboost-regex1.74

plesk-libboost-serialization1.74

plesk-libboost-system1.74

plesk-libboost-thread1.74



plesk-libboost-1.79

plesk-libboost-chrono1.79

plesk-libboost-date-time1.79

plesk-libboost-filesystem1.79

plesk-libboost-iostreams1.79

plesk-libboost-locale1.79

plesk-libboost-program-options1.79

plesk-libboost-regex1.79

plesk-libboost-serialization1.79

plesk-libboost-system1.79

plesk-libboost-thread1.79



plesk-libboost-1.80

plesk-libboost-chrono1.80

plesk-libboost-date-time1.80

plesk-libboost-filesystem1.80

plesk-libboost-iostreams1.80

plesk-libboost-locale1.80

plesk-libboost-program-options1.80

plesk-libboost-regex1.80

plesk-libboost-serialization1.80

plesk-libboost-system1.80

plesk-libboost-thread1.80



plesk-libboost-1.82

plesk-libboost-chrono1.82

plesk-libboost-date-time1.82

plesk-libboost-filesystem1.82

plesk-libboost-iostreams1.82

plesk-libboost-locale1.82

plesk-libboost-program-options1.82

plesk-libboost-regex1.82

plesk-libboost-serialization1.82

plesk-libboost-system1.82

plesk-libboost-thread1.82



plesk-libboost-chrono1.65

plesk-libboost-locale1.65

plesk-libboost-chrono1.74

plesk-libboost-locale1.74

plesk-libboost-chrono1.79

plesk-libboost-locale1.79

plesk-libboost-chrono1.80

plesk-libboost-locale1.80

plesk-libboost-chrono1.82

plesk-libboost-locale1.82



plesk-libboost-date-time1.65

plesk-libboost-date-time1.74

plesk-libboost-date-time1.79

plesk-libboost-date-time1.80

plesk-libboost-date-time1.82



plesk-libboost-filesystem1.65

plesk-libboost-filesystem1.74

plesk-libboost-filesystem1.79

plesk-libboost-filesystem1.80

plesk-libboost-filesystem1.82



plesk-libboost-iostreams1.65

plesk-libboost-iostreams1.74

plesk-libboost-iostreams1.79

plesk-libboost-iostreams1.80

plesk-libboost-iostreams1.82



plesk-libboost-locale1.65

plesk-libboost-locale1.74

plesk-libboost-locale1.79

plesk-libboost-locale1.80

plesk-libboost-locale1.82



plesk-libboost-program-options1.65

plesk-libboost-program-options1.74

plesk-libboost-program-options1.79

plesk-libboost-program-options1.80

plesk-libboost-program-options1.82



plesk-libboost-regex1.65

plesk-libboost-regex1.74

plesk-libboost-regex1.79

plesk-libboost-regex1.80

plesk-libboost-regex1.82



plesk-libboost-serialization1.65

plesk-libboost-serialization1.74

plesk-libboost-serialization1.79

plesk-libboost-serialization1.80

plesk-libboost-serialization1.82



plesk-libboost-thread1.65

plesk-libboost-locale1.65

plesk-libboost-thread1.74

plesk-libboost-locale1.74

plesk-libboost-thread1.79

plesk-libboost-locale1.79

plesk-libboost-thread1.80

plesk-libboost-locale1.80

plesk-libboost-thread1.82

plesk-libboost-locale1.82

~
~#

In each of the above cases, there's a later package version, which is not orphaned e.g.

plesk-libboost-1.84
plesk-libboost-chrono1.84
plesk-libboost-date-time1.84
plesk-libboost-filesystem1.84
plesk-libboost-iostreams1.84
plesk-libboost-locale1.84
plesk-libboost-program-options1.84
plesk-libboost-regex1.84
plesk-libboost-serialization1.84
plesk-libboost-system1.84
plesk-libboost-thread1.84

plesk-libboost-chrono1.84
plesk-libboost-locale1.84
plesk-service-node-utilities

plesk-libboost-date-time1.84
libaps
plesk-lmlib
plesk-service-node-utilities
sw-engine
sw-engine-cli-6.61

etc etc

All of these then, could / shouold be suitable for removal as part of the Plesk 'clean up'. Would you agree?

 

[Hangover2]

@learning_curve The command...

aptitude search '?obsolete'

... should be used carefully. Plesk has temporary sources while updating the base system (e.g. 50sw_autoinstaller.list). In that moment many packages are not in the list of "Obsolete and Locally Created Packages" anymore. After the update procedure is finished those sources are deleted again or reverted back to their original state leading to an increased number of obsolete/locally created packages.

 

[learning_curve]

@learning_curve The command...

... should be used carefully. Plesk has temporary sources while updating the base system (e.g. 50sw_autoinstaller.list). In that moment many packages are not in the list of "Obsolete and Locally Created Packages" anymore. After the update procedure is finished those sources are deleted again or reverted back to their original state leading to an increased number of obsolete/locally created packages.

Very True. Hence us only being focused on sw-engine-cli-* and pp*-bootstrapper packages initially, which, as per post #15 are all completely 'cleaned up' now.
deborphan is not perfect (it still has registered bugs on Ubuntu) but there's a lot of variables and filters than can be applied when focusing on certain areas / files / packages etc We've used that in post #16 as part of continuing with the 'clean ups', but we'll act on that only after a reply from plesk.

 

[learning_curve]

~ But your are definitely welcome to add as a suggestion on our UserVoice ~

Done. Will post a separate thread once this becomes a live suggestion.

 

[learning_curve]

~~ In each of the above cases, there's a later package version, which is not orphaned e.g.
~~
etc etc
~~
All of these then, could / should be suitable for removal as part of the Plesk 'clean up'. Would you agree?

Any news / thoughts on this dataset @Kaspar@Plesk