Resolved HELP! Update stuck with Plesk Onyx 17.8.11#1

[MarkM]

Maybe;

package-cleanup --cleandupes

Edit; looks like someone posted a better answer at the same time as me.

 

[Sergio Manzi]

Thanks, @themew!

Yup! "yum-complete-transaction" is exactly what yum itself suggested.
But I have small (noob) issue:

# yum-complete-transaction
-bash: yum-complete-transaction: command not found

 

[themew]

Skip the 'yum-complete-transaction' and begin with the next command 'package-cleanup --problems' and continue until you're updated without errors.

 

[Sergio Manzi]

I hate to tell you, but...

# package-cleanup --help
-bash: package-cleanup: command not found

 

[Sergio Manzi]

where do those two commands come from? Am I missing some (system) package?

 

[themew]

One more shot using these 2 commands:

yum-complete-transaction --cleanup-only
yum clean all
yum update

See if that works for you...

 

[Sergio Manzi]

the first is impossible (I don't have that command installed...)
the last two, I already did, but I'm giving it a second shot... wait...

 

[Sergio Manzi]

OK, it seems I need to "yum install yum-utils" to get those commands... (hold on, if you can...)

 

[Sergio Manzi]

soooo...

# yum install yum-utils
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.ams1.nl.leaseweb.net
 * epel: ftp.nluug.nl
 * extras: mirror.ams1.nl.leaseweb.net
 * updates: mirror.ams1.nl.leaseweb.net
Resolving Dependencies
There are unfinished transactions remaining. You might consider running yum-complete-transaction, or "yum-complete-transaction --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).
The program yum-complete-transaction is found in the yum-utils package.
--> Running transaction check
---> Package yum-utils.noarch 0:1.1.31-42.el7 will be installed
--> Processing Dependency: python-kitchen for package: yum-utils-1.1.31-42.el7.noarch
--> Running transaction check
---> Package python-kitchen.noarch 0:1.1.1-5.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

====================================================================================================================================
 Package                             Arch                        Version                            Repository                 Size
====================================================================================================================================
Installing:
 yum-utils                           noarch                      1.1.31-42.el7                      base                      117 k
Installing for dependencies:
 python-kitchen                      noarch                      1.1.1-5.el7                        base                      267 k

Transaction Summary
====================================================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 384 k
Installed size: 1.7 M
Is this ok [y/d/N]: y
Downloading packages:
(1/2): yum-utils-1.1.31-42.el7.noarch.rpm                                                                    | 117 kB  00:00:00
(2/2): python-kitchen-1.1.1-5.el7.noarch.rpm                                                                 | 267 kB  00:00:00
------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                               2.8 MB/s | 384 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : python-kitchen-1.1.1-5.el7.noarch                                                                                1/2
  Installing : yum-utils-1.1.31-42.el7.noarch                                                                                   2/2
  Verifying  : yum-utils-1.1.31-42.el7.noarch                                                                                   1/2
  Verifying  : python-kitchen-1.1.1-5.el7.noarch                                                                                2/2

Installed:
  yum-utils.noarch 0:1.1.31-42.el7

Dependency Installed:
  python-kitchen.noarch 0:1.1.1-5.el7

Complete!
[root@ams301 ~]# yum-complete-transaction
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.ams1.nl.leaseweb.net
 * epel: ftp.nluug.nl
 * extras: mirror.ams1.nl.leaseweb.net
 * updates: mirror.ams1.nl.leaseweb.net
There are 1 outstanding transactions to complete. Finishing the most recent one
The remaining transaction had 22 elements left to run
--> Running transaction check
---> Package cloud-init.x86_64 0:0.7.9-9.el7.centos.2 will be erased
---> Package iptables.x86_64 0:1.4.21-18.2.el7_4 will be erased
---> Package libgcc.x86_64 0:4.8.5-16.el7_4.1 will be erased
---> Package libgomp.x86_64 0:4.8.5-16.el7_4.1 will be erased
---> Package libgudev1.x86_64 0:219-42.el7_4.7 will be erased
---> Package libstdc++.x86_64 0:4.8.5-16.el7_4.1 will be erased
---> Package libteam.x86_64 0:1.25-5.el7 will be erased
---> Package php.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package php-cli.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package php-common.x86_64 0:5.4.16-43.el7_4 will be erased
--> Processing Dependency: php-common(x86-64) = 5.4.16-43.el7_4 for package: php-fpm-5.4.16-43.el7_4.x86_64
---> Package php-gd.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package php-mbstring.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package php-mysql.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package php-pdo.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package php-xml.x86_64 0:5.4.16-43.el7_4 will be erased
---> Package python-perf.x86_64 0:3.10.0-693.17.1.el7 will be erased
---> Package selinux-policy.noarch 0:3.13.1-166.el7_4.7 will be erased
---> Package selinux-policy-targeted.noarch 0:3.13.1-166.el7_4.7 will be erased
---> Package systemd.x86_64 0:219-42.el7_4.7 will be erased
---> Package systemd-libs.x86_64 0:219-42.el7_4.7 will be erased
---> Package systemd-sysv.x86_64 0:219-42.el7_4.7 will be erased
---> Package teamd.x86_64 0:1.25-5.el7 will be erased
--> Running transaction check
---> Package php-fpm.x86_64 0:5.4.16-43.el7_4 will be erased
--> Finished Dependency Resolution

Dependencies Resolved


Transaction size changed - this means we are not doing the
same transaction as we were before. Aborting and disabling
this transaction.

You could try running: package-cleanup --problems
                       package-cleanup --dupes
                       rpm -Va --nofiles --nodigest

Transaction files renamed to:
  /var/lib/yum/transaction-all.2018-03-09.04:11.21.disabled
  /var/lib/yum/transaction-done.2018-03-09.04:11.21.disabled
[root@ams301 ~]# package-cleanup --problems
Loaded plugins: fastestmirror
No Problems Found
[root@ams301 ~]# package-cleanup --dupes
Loaded plugins: fastestmirror
php-mbstring-5.4.16-43.el7_4.x86_64
php-mbstring-5.4.16-43.el7_4.1.x86_64
libgudev1-219-42.el7_4.7.x86_64
libgudev1-219-42.el7_4.10.x86_64
libstdc++-4.8.5-16.el7_4.1.x86_64
libstdc++-4.8.5-16.el7_4.2.x86_64
php-xml-5.4.16-43.el7_4.1.x86_64
php-xml-5.4.16-43.el7_4.x86_64
libgcc-4.8.5-16.el7_4.1.x86_64
libgcc-4.8.5-16.el7_4.2.x86_64
selinux-policy-targeted-3.13.1-166.el7_4.7.noarch
selinux-policy-targeted-3.13.1-166.el7_4.9.noarch
systemd-219-42.el7_4.10.x86_64
systemd-219-42.el7_4.7.x86_64
php-5.4.16-43.el7_4.1.x86_64
php-5.4.16-43.el7_4.x86_64
python-perf-3.10.0-693.21.1.el7.x86_64
python-perf-3.10.0-693.17.1.el7.x86_64
php-mysql-5.4.16-43.el7_4.x86_64
php-mysql-5.4.16-43.el7_4.1.x86_64
php-common-5.4.16-43.el7_4.x86_64
php-common-5.4.16-43.el7_4.1.x86_64
php-gd-5.4.16-43.el7_4.x86_64
php-gd-5.4.16-43.el7_4.1.x86_64
iptables-1.4.21-18.3.el7_4.x86_64
iptables-1.4.21-18.2.el7_4.x86_64
systemd-libs-219-42.el7_4.7.x86_64
systemd-libs-219-42.el7_4.10.x86_64
cloud-init-0.7.9-9.el7.centos.2.x86_64
cloud-init-0.7.9-9.el7.centos.6.x86_64
php-pdo-5.4.16-43.el7_4.1.x86_64
php-pdo-5.4.16-43.el7_4.x86_64
selinux-policy-3.13.1-166.el7_4.9.noarch
selinux-policy-3.13.1-166.el7_4.7.noarch
libteam-1.25-5.el7.x86_64
libteam-1.25-6.el7_4.3.x86_64
php-fpm-5.4.16-43.el7_4.1.x86_64
php-fpm-5.4.16-43.el7_4.x86_64
libgomp-4.8.5-16.el7_4.2.x86_64
libgomp-4.8.5-16.el7_4.1.x86_64
php-cli-5.4.16-43.el7_4.1.x86_64
php-cli-5.4.16-43.el7_4.x86_64
teamd-1.25-5.el7.x86_64
teamd-1.25-6.el7_4.3.x86_64
systemd-sysv-219-42.el7_4.7.x86_64
systemd-sysv-219-42.el7_4.10.x86_64
[root@ams301 ~]# rpm -Va --nofiles --nodigest
[root@ams301 ~]#

TLDR;

I did the yum-complete-transaction and I was suggested to do:

package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest

... which I did...

Now let me see what a yum check has to say (but it is quite a slow process...)

 

[Sergio Manzi]

... and while "yum check" is running (reaaaaly slooow) I'm wondering if it would be wise to do a "yum reinstall" for each of the 23 problematic packages...

 

[Sergio Manzi]

Yum check says that all the dupes are still there...
I'm going with the -cleandupes

 

[Sergio Manzi]

Now yum is OK, but I still have "Warning: Information on some packages might not be actual: inconsistencies were detected in the system's package manager database. Please resolve this issue manually." in Plesk panel.

Now, anyway, I want to risk and... reboot: this is a good time for breaking things!

Thanks @themew your instructions were so far spot-on!

 

[Sergio Manzi]

WOW! It rebooted, and not only that: now the warning in "System Updates" is gone!

One more thing is gone: "Automatically install Plesk updates (Recommended)"!

Thanks again everybody!

But now... don't you think this update behavior is... anomalous? A little bit buggy, I would dare to say...

Should we open a formal report? What's your opinion, guys?

 

[Bitpalast]

Yes, please create a bug report! I have had similar issues several times on updates from 12.5 to 17.5 and I would just love to see that Plesk invests much, much, much more effort into the update functions instead of adding new gimmicks. The whole story is about reliability and availability of a host system. Update failures like this can cause hours, maybe even days of offline time that are inacceptable to end users. These issues should really be fixed.

 

[Sergio Manzi]

I totally agree @Peter Debik!

So, according to your experience, this is a long standing issue and the fact that to me it happened just after upgrading to 17.8.11 is a case of coincidence, due to CentOS php-fpm having been upgraded just at that time, correct?

 

[Bitpalast]

To me it remained unclear why this is happening. I can only say that we have had the "duplicates" issue on updates from 12.5 to 17.5 before. It was not possible to determine the reason. I think it is a buggy upgrade process, because to this date I have not yet experienced an upgrade that went through without issues. The "duplicates" issue is not the only one.

 

[Sergio Manzi]

In this case I'm quite sure the issue was triggered by me killing the PUM process, which was stuck on "systemctl try-restart php-fpm.service".

So, I think there is an issue by itself here (the stuck service restart)...

Then, there is a more general issue that when PUM fails, for whatever reason, you face consequences of inconsistent update status, like the dupes I have had...

 

[Sergio Manzi]

tomorrow (or later tonight) I will write a bug report...

 

[Sergio Manzi]

• Filed report: Update hung with PHP 5.4.16 by OS vendor FPM application disabled
• Marking this as solved

@Peter Debik You're welcome to add your comments in the report too...