[case EA-6287] EasyApache 4 UI fails to load with UTF-8 error - The subprocess error
I have rebooted the server but to no avail. When opening the EasyApache 4 UI in WHM and trying to customise any package including any of the cPanel defaults, it hangs on "loading packages" and according to Firefox Developer Tools an HTTP 500 error is occurring with the response:
{"metadata":{"result":0,"version":1,"reason":"No response from subprocess (whostmgr (xml-api)): The subprocess reported error number 255 when it ended."},"data":null}
It was working fine this morning and now it's not. Any ideas why?
-
Same exact issue. I saw this: Error: 500 No response from subprocess (whostmgr (cpanel)) BUT it didn't work for me. more info from log: [2017-05-17 08:06:58 -0500] die [Internal Death while parsing [stdin] 31829] Wide character in syswrite at whostmgr/bin/xml-api.pl line 2962. at whostmgr/bin/xml-api.pl line 2962. whostmgr::bin::xml_api::__ANON__(__CPANEL_HIDDEN__...) called at whostmgr/bin/xml-api.pl line 3250 whostmgr::bin::xml_api::runapp("package_manager_get_package_info", HASH(0x53627b8), HASH(0x2f3fee8), 0, CODE(0x51a9ab8)) called at whostmgr/bin/xml-api.pl line 3008 whostmgr::bin::xml_api::script(CODE(0x51a9ab8), "-json", "./package_manager_get_package_info") called at whostmgr/bin/xml-api.pl line 2962 Wide character in syswrite at whostmgr/bin/xml-api.pl line 2962.0 -
I am having the same problem. stuck at "Loading packages "" 0 -
64.0.21 I can't get past the "Loading Packages" either when I try Customize any package. Log: [2017-05-17 13:42:34 +0000] die [Internal Death while parsing [stdin] 93524] Wide character in syswrite at whostmgr/bin/xml-api.pl line 2962. at whostmgr/bin/xml-api.pl line 2962. whostmgr::bin::xml_api::__ANON__(__CPANEL_HIDDEN__...) called at whostmgr/bin/xml-api.pl line 3250 whostmgr::bin::xml_api::runapp("package_manager_get_package_info", HASH(0x5638480), HASH(0x2f3fee8), 0, CODE(0x59d3aa8)) called at whostmgr/bin/xml-api.pl line 3008 whostmgr::bin::xml_api::script(CODE(0x59d3aa8), "-json", "./package_manager_get_package_info") called at whostmgr/bin/xml-api.pl line 2962 Wide character in syswrite at whostmgr/bin/xml-api.pl line 2962.
I think someone broke it ......slap....slap....slap :-p0 -
Hello, This is being caused by a UTF-8 character in the ruby RPMs that we shipped yesterday. We'll have packages published shortly that will fix this issue. 0 -
Whilst Jacob was posting, I was busy doing a Home " cPanel " Upgrade to Latest Version with the force flag set (you know, someone always asks if you did one to see if it fixes the error - it didn't !) and I was somewhat unimpressed with the huge new log output box that now shows a massive EIGHT lines at once. Come on guys - we seem to be going backwards with updates at the moment :( 0 -
Hello, This is being caused by a UTF-8 character in the ruby RPMs that we shipped yesterday. We'll have packages published shortly that will fix this issue.
Roll it back? Surely if you've released one thing that breaks another, in the very first instance you should be rolling the change back while a proper fix is created?0 -
i have the same problem. stuck at "Loading packages "". is there any ETA to solve the problem? 0 -
We are reporting the same thing on several cPanel servers here too 0 -
Same issue for us. FYI one fix is clicking "Provision" for the default profile in easyapache4... but there is no way to customize it. This is an urgent issue that needs fixing. 0 -
I have exactly the same issue on my development server (stuck at "Loading packages "") CENTOS 7.3 x86_64 standard cPanel & WHM 64.0 (build 21 This happened after upgrading mysql to mariadb so i'm going to leave the upgrade on my production server until this is rectified.... I have also tried "yum clean all" to no avail. edit: Just to note i've just checked my production server and can add extra packages to it fine! this is also running on CENTOS 7.3 x86_64 standard - cPanel & WHM 64.0 (build 21) 0 -
Same issue here CENTOS 6.9 x86_64 xen hvm " cPanel & WHM 64.0 (build 21) I have to admit, as a cPanel customer for a decade I am extremely disappointed. I stick to the stable versions on my production servers for a reason! No client wants to here "Its the vendors fault" 0 -
Come on guys.. got three new servers I can't complete because of this - plus a current server that needs an Apache module adding ASAP.. I love your product - but this should have been caught in testing! o_O 0 -
We have also had this issue today on a couple of servers and am also extremely disappointed that this got this far. We have been told there is a case open (EA-6287) but we have no visibility into these ! Our case is DSO as well although there was a workaround by switching to PHP5.5 from the server default which was set to 5.6
Switching to PHP 5.5 didnt work for me. I attempted to provision the default and not all the sites are internal server error.0 -
Same here, i deploy today 2 new VPS and i stuck and is frustrating. I Stuck in loading packages also. 0 -
I've been updated on a ticket that a fix for this EA-6287 will be available within the next few hours. 0 -
Hi, We're working to get fixed packages out today to get this taken care of. We should have a fix published in the next few hours. 0 -
Can we get an ETA on what a few hours is? This has caused me to lose quite a lot of customers. Sigh 0 -
Whats the status? 0 -
Same here, our firm has already received numerous blowback's on social and well as direct complaints by phone and trouble tickets. I would this this would to be an immediate fix. 0 -
Same here, our firm has already received numerous blowback's on social and well as direct complaints by phone and trouble tickets. I would this this would to be an immediate fix.
I'm surprised this has happened and there has been no rollback. cPanel has always had a reputation for taking the time to implement new features for quality reasons but in this case it looks like no testing has been done and no one has bothered to undo the change. I appreciate they may be working to fix it, but as a developer I would at the very least roll the change back and, while people can use the system as normal, work on a fix in the meantime. Don't understand why this hasn't happened? Some clarification would help please...0 -
The fix for this has been tested and is now in the publication process. It will take a few hours to publish. Since Easyapache uses yum to manage packages, the process of rolling back or pushing new updates takes more time than the process for pulling cPanel updates. 0 -
sorry but if the solution is CENTOS 6.9 x86_64 standard " server cPanel & WHM 64.0 (build 22) it is still the same for me. am i missing something? 0 -
Hello, The fix is publishing to the mirrors at this time. I'll update once we've confirmed we're good to go. Thanks for your patience 0 -
The publication process is nearly completed. Most update servers now have the fixed ruby packages that will resolve this problem. The system should automatically see the fixed packages with tonight's update. If waiting for the update is not an option, the UI can be restored sooner by clearing the yum cache. To clear the cache and force yum to re-examine the repository, please run the following on the command line: yum clean all0 -
Hello, This issue is now resolved, and the metadata on the mirrors will allow the EA4 UI to work again. As Nick stated, a yum clean all may be needed 0 -
Updated both my development and production servers and it's now working fine. Many thanks 0 -
Working for me too, thanks! 0 -
I can also confirm that this has resolved the issues and all systems are working as expected. Now to send out the apology emails and accept responsibility for an unprecedented amount of downtime. Special thanks to cPanel's Sky Bly for all the assistance provided in getting our datacenter back online yesterday. 0 -
Confirmed on our dozen or so servers. Thank you for making this a priority!!! Awesome service as always. 0
Please sign in to leave a comment.
Comments
29 comments