Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

cPanel & WHM update failure in upcp script

Discussion in 'General Discussion' started by Nirjonadda, Jan 5, 2018.

  1. Nirjonadda

    Nirjonadda Well-Known Member

    Joined:
    May 8, 2013
    Messages:
    557
    Likes Received:
    14
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    I am getting email about cPanel & WHM update failure in upcp script.

    The cPanel & WHM update process failed for the following reason:

    Code:
     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
    Code:
    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=<repoid> ...
    [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 <repoid>
    [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=<repoid>
    [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=<repoid>.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
    Code:
    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 
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

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

    Code:
    yum clean all
    yum update
    Thank you.
     
Loading...

Share This Page