Article ID: 114650, created on Aug 27, 2012, last review on May 10, 2014

  • Applies to:
  • Operations Automation 5.3

Symptoms


The main symptom is that POA, in general, is unstable:
  • Customers cannot log in to POA Control Panel and they see the error message An unforeseen error occurred.
  • Subscriptions cannot be created from PBA using the API method pem.activateSubscription.
  • Many core dumps are being created in the /usr/local/pem/var/cores/ folder on the POA Management Node within a short period of time, like in the example below:
-rw------- 1 pemuser pemgroup   39116800 Aug 22 16:02 core.25773
-rw------- 1 pemuser pemgroup   39313408 Aug 22 16:07 core.29354
-rw------- 1 pemuser pemgroup   34865152 Aug 22 16:11 core.618
-rw------- 1 pemuser pemgroup   35573760 Aug 22 16:16 core.3768
-rw------- 1 pemuser pemgroup   39714816 Aug 22 16:22 core.6839
-rw------- 1 pemuser pemgroup  804950016 Aug 22 16:31 core.11231
-rw------- 1 pemuser pemgroup   30896128 Aug 22 16:36 core.26975
-rw------- 1 pemuser pemgroup   45338624 Aug 22 16:49 core.30053
-rw------- 1 pemuser pemgroup   45322240 Aug 22 16:55 core.8446
  • The existence of many core dumps indicates that errors are appearing after the procedure getUpgradeStepsSequence, like in the example below:
(gdb) bt #0  0xb42b4c32 in std::_Rb_tree<std::string, std::pair<std::string const, std::map<std::string, char, std::less<std::string>, std::allocator<std::pair<std::string const, char> > > >, std::_Select1st<std::pair<std::string const, std::map<std::string, char, std::less<std::string>, std::allocator<std::pair<std::string const, char> > > > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::map<std::string, char, std::less<std::string>, std::allocator<std::pair<std::string const, char> > > > > >::lower_bound () from /usr/local/pem/libexec/APS.so.5.3.0.125
#1  0xb42b834d in std::map<std::string, std::map<std::string, char, std::less<std::string>, std::allocator<std::pair<std::string const, char> > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::map<std::string, char, std::less<std::string>, std::allocator<std::pair<std::string const, char> > > > > >::operator[] () from /usr/local/pem/libexec/APS.so.5.3.0.125
#2  0xb42b3093 in Plesk::APS::getUpgradeStepsSequence () from /usr/local/pem/libexec/APS.so.5.3.0.125
#3  0xb42b3a16 in Plesk::APS::APSManager_impl::upgradeApplicationInstance () from /usr/local/pem/libexec/APS.so.5.3.0.125
#4  0xb44d5dff in POA_Plesk::APS::upgradeApplicationInstance_APSManager::execute () from /usr/local/pem/libexec/APS.so.5.3.0.125

The problem affects POA 5.3 only.

Cause

The reason for the problem has to do with APS controller tasks:
  • Update instances of APS applications scheduled for update.
  • Reconfigure instances of APS applications scheduled for reconfiguration.
  • Synchronize resource usage for instances of APS applications.
During the tasks' execution, the corresponding SoLoader process fails and generates a core dump, and in the 5 minutes after that, it affects the execution of other POA tasks (until POA repairs the SoLoader process).

Resolution

Upgrade POA to 5.3.14 or a later version.

If an upgrade is not possible, as a workaround, change the period of the above-listed POA periodic tasks to a large value, e.g., once a week or day.

Important: After POA is upgraded to 5.3.14 or a later version, change the period for POA tasks back to the proper value.

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae a8cdca46e4357a6e38fded820770e272 2554725ed606193dd9bbce21365bed4e e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF