cPanel & WHM update failure in upcp script

I am getting email about cPanel & WHM update failure in upcp script. The cPanel & WHM update process failed for the following reason:

 Maintenance ended; however, it did not exit cleanly (256). Review the update logs to determine why the update failed.

Update log preview:
[2018-01-05 21:49:15 +0600] Processing: Checking for deprecated PHP local.ini
[2018-01-05 21:49:15 +0600] - Processing command `/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini --run --verbose`
[2018-01-05 21:49:15 +0600] [/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini] Processing ea-php72 "
[2018-01-05 21:49:15 +0600] [/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini] No local.ini.
[2018-01-05 21:49:15 +0600] [/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini] " done!
[2018-01-05 21:49:15 +0600] - Finished command `/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini --run --verbose` in 0.093 seconds
[2018-01-05 21:49:15 +0600] 92% complete
[2018-01-05 21:49:15 +0600] 93% complete
[2018-01-05 21:49:15 +0600] - Finished in 0.018 seconds
[2018-01-05 21:49:15 +0600] Processing: Ensuring an "Active" MySQL profile is set
[2018-01-05 21:49:15 +0600] - Processing command `/usr/local/cpanel/scripts/check_mysql`
[2018-01-05 21:49:15 +0600] [/usr/local/cpanel/scripts/check_mysql] "check_mysql" will complete in the background (process ID 10880).
[2018-01-05 21:49:15 +0600] - Finished command `/usr/local/cpanel/scripts/check_mysql` in 0.109 seconds
[2018-01-05 21:49:15 +0600] Processing: Checking CloudLinux installation
[2018-01-05 21:49:15 +0600] - Processing command `/usr/local/cpanel/bin/cloudlinux_update`
[2018-01-05 21:49:15 +0600] - Finished command `/usr/local/cpanel/bin/cloudlinux_update` in 0.074 seconds
[2018-01-05 21:49:15 +0600] 94% complete
[2018-01-05 21:49:15 +0600] Processing: Updating plugins data cache
[2018-01-05 21:49:15 +0600] - Processing command `/usr/local/cpanel/bin/refresh_plugin_cache`
[2018-01-05 21:49:15 +0600] - Finished command `/usr/local/cpanel/bin/refresh_plugin_cache` in 0.024 seconds
[2018-01-05 21:49:15 +0600] 95% complete
=> Log closed Fri Jan 5 21:49:15 2018
----------------------------------------------------------------------------------------------------
=> Log opened from cPanel Update (upcp) - Slave (10168) at Fri Jan 5 21:49:15 2018
[2018-01-05 21:49:15 +0600] E Pre Maintenance ended, however it did not exit cleanly (256). Please check the logs for an indication of what happened

2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup] (XID qjd3bq) The system failed to execute yum with the arguments "--assumeyes --config /etc/yum.conf update ea-apache24 ea-apache24-config --disablerepo=epel" because of an error: The "/usr/bin/yum" command (process 10207) reported error number 1 when it ended. :
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]  One of the configured repositories failed (Unknown),
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]  and yum doesn't have enough cached data to continue. At this point the only
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]  safe thing yum can do is fail. There are a few ways to work "fix" this:
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]      1. Contact the upstream for the repository and get them to fix the problem.
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]      2. Reconfigure the baseurl/etc. for the repository, to point to a working
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        upstream. This is most often useful if you are using a newer
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        distribution release than is supported by the repository (and the
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        packages for the previous distribution release still work).
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]      3. Run the command with the repository temporarily disabled
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]            yum --disablerepo= ...
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]      4. Disable the repository permanently, so yum won't use it by default. Yum
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        will then just ignore the repository until you permanently enable it
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        again or use --enablerepo for temporary usage:
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]            yum-config-manager --disable 
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        or
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]            subscription-manager repos --disable=
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]      5. Configure the failing repository to be skipped, if it is unavailable.
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        Note that yum will try to contact the repo. when it runs most commands,
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        so will have to try and fail each time (and thus. yum will be be much
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        slower). If it is a very temporary problem though, this is often a nice
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]        compromise:
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]            yum-config-manager --save --setopt=.skip_if_unavailable=true
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup]
[2018-01-05 21:45:15 +0600]      [/usr/local/cpanel/scripts/sysup] Parsing primary.xml error: Document is empty

New Security Advisor notifications with Medium importance
    
Type     Module     Advice
? Medium     Kernel     The system cannot check the kernel status: "/usr/bin/yum" reported error code "1" when it ended: One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo= ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable or subscription-manager repos --disable= 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt= .skip_if_unavailable=true Parsing primary.xml error: Document is empty
? Medium     Processes     Failed to check whether active services are up-to-date: "/usr/local/cpanel/bin/needs-restarting-cpanel" reported error code "1" when it ended: Parsing primary.xml error: Document is empty
? Medium     Processes     Failed to check whether running executables are up-to-date: "/usr/local/cpanel/bin/needs-restarting-cpanel" reported error code "1" when it ended: Parsing primary.xml error: Document is empty

cPanelMichael

January 05, 2018 17:07

Hello, It looks like YUM is unable to successfully update. Try running the following commands to see if it fixes the issue:

yum clean all
yum update

Thank you.

uk01

June 10, 2018 00:51

Hi similar issue here, updated to mariaDB 10.1 last night. Now tonight we get cpanel update failure Failed to check whether active services are up-to-date: "/usr/local/cpanel/bin/needs-restarting-cpanel" reported error code "1" when it ended: failure: repodata/86c57bc5e2c748bc34491e2a47b19182435730df45d862296a3db58405c05b4b-filelists.sqlite.bz2 from MariaDB101: [Errno 256] No more mirrors to try.

June 10, 2018 00:54

ah, looks like mariadb.org server is down for everything, so that's probably it

Jcats

June 10, 2018 02:09

It is indeed, for now add this to your /etc/hosts file

192.99.47.208 yum.mariadb.org

June 11, 2018 14:15

Hello, To update, it looks MariaDB has addressed the issue and yum.mariadb.org now resolves. Thank you.

cPanel & WHM update failure in upcp script

Comments

Didn't find what you were looking for?