SOLVED Fatal Error When Creating Account

[mrx13689]

Plz Help

I encountered an error after updating to the latest version "
A fatal error or timeout occurred while processing this directive."

[2017-04-12 12:28:37 +0000] die [Internal Death while parsing [stdin] 2260] No “program”! at /usr/local/cpanel/Cpanel/SafeRun/Object.pm line 115.
 at /usr/local/cpanel/Cpanel/SafeRun/Object.pm line 115.
    Cpanel::SafeRun::Object::new("Cpanel::SafeRun::Object", "program", "", "args", ARRAY(0x339bc60), "stderr", GLOB(0x53ae708)) called at /usr/local/cpanel/Cpanel/CachedCommand.pm line 165
    Cpanel::CachedCommand::_get_cmd_output("program", "", "args", ARRAY(0x339bc60), "stderr", GLOB(0x53ae708)) called at /usr/local/cpanel/Cpanel/CachedCommand.pm line 139
    Cpanel::CachedCommand::_cached_cmd("binary", undef, "regexcheck", Regexp=REGEXP(0x68caaf8), "args", ARRAY(0x33e83b8)) called at /usr/local/cpanel/Cpanel/CachedCommand.pm line 192
    Cpanel::CachedCommand::cachedcommand(undef, "--version") called at /usr/local/cpanel/Cpanel/GlobalCache.pm line 62
    Cpanel::GlobalCache::cachedcommand("cpanel", undef, "--version") called at /usr/local/cpanel/Cpanel/PostgresAdmin/Check.pm line 59
    Cpanel::PostgresAdmin::Check::is_configured() called at /usr/local/cpanel/Cpanel/Validate/DB.pm line 254
    Cpanel::Validate::DB::is_valid_dbowner("heefcttct2017") called at /usr/local/cpanel/Whostmgr/Accounts/Create.pm line 511
    Whostmgr::Accounts::Create::_wwwacct(__CPANEL_HIDDEN__, 0, __CPANEL_HIDDEN__, __CPANEL_HIDDEN__, __CPANEL_HIDDEN__, __CPANEL_HIDDEN__, __CPANEL_HIDDEN__, __CPANEL_HIDDEN__, ...) called at /usr/local/cpanel/Whostmgr/Accounts/Create.pm line 1951
    Whostmgr::Accounts::Create::__createaccount("maxftp", "unlimited", "customip", "--Auto Assign--", "dbuser", "username", "domain", "domain.tld", ...) called at /usr/local/cpanel/Whostmgr/Accounts/Create.pm line 2001
    Whostmgr::Accounts::Create::_createaccount("maxftp", "unlimited", "customip", "--Auto Assign--", "dbuser", "username", "domain", "domain.tld", ...) called at whostmgr/bin/whostmgr5.pl line 753
    main::wwwacct() called at whostmgr/bin/whostmgr5.pl line 228

 

[cPanelMichael]

Hello,

Internal case CPANEL-12578 is open to address an issue where removing the postgresql-server RPM from a system, while leaving the remaining PostgreSQL packages installed, results in an error message like this when attempting to create a new account in WHM:

die [Internal Death while parsing [stdin] 91906] No “program”! at /usr/local/cpanel/Cpanel/SafeRun/Object.pm line 115.

 at /usr/local/cpanel/Cpanel/SafeRun/Object.pm line 115.

I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can address the issue by installing PostgreSQL (if you want it on your system):

/scripts/installpostgres --force

Thank you.

Update:

Internal case CPANEL-12578 is fixed as of cPanel 64.0.12:

Fixed case CPANEL-12578: Ensure cached command running fails gracefully.

Note this case doesn't actually remove the incomplete PostgreSQL installation, but rather it allows the account creation process to succeed on systems where PostgreSQL isn't fully uninstalled.

 

[yairp]

do not do the second suggestion!

rpm -qa|grep postgresql
yum remove $full-package-name-from-output

I did it and now I get


Internal Server Error
500

No response from subprocess (whostmgr (whostmgr2)): The subprocess reported error number 127 when it ended.




in many places so my WHM is ***** up

 

[cPanelMichael]

rpm -qa|grep postgresql
yum remove $full-package-name-from-output

Hello,

I updated the previous post to remove the "yum remove $full-package-name-from-output" advice, however it should not have resulted in any issues if you only removed the PostgreSQL RPMS. Which specific commands did you run?

Thank you.

 

[cPanelMichael]

Hello,

To update, internal case CPANEL-12578 is fixed as of cPanel 64.0.12:

Fixed case CPANEL-12578: Ensure cached command running fails gracefully.

Note this case doesn't actually remove the incomplete PostgreSQL installation, but rather it allows the account creation process to succeed on systems where PostgreSQL isn't fully uninstalled.

Thank you.

 

[totalchoice]

Hello,

I updated the previous post to remove the "yum remove $full-package-name-from-output" advice, however it should not have resulted in any issues if you only removed the PostgreSQL RPMS. Which specific commands did you run?

Thank you.

I know this case is now resolved but I wanted to point out that the command provided returns cpanel-postgresql-libs and cpanel-postgresql. We had several clients try this fix and then had to repair their cPanel installs.

This could have been avoided with:

rpm -qa|grep postgresql |grep -v cpanel
yum remove $full-package-name-from-output

Here is the truncated results of when you run yum remove cpanel-postgresql-libs:

# yum remove cpanel-postgresql-libs
Loaded plugins: changelog, fastestmirror, security, universal-hooks
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package cpanel-postgresql-libs.x86_64 0:9.0.18-1.cp1156 will be erased
--> Processing Dependency: cpanel-postgresql-libs >= 9.0.18-1 for package: cpanel-php56-5.6.30-2.cp1164.x86_64
--> Processing Dependency: cpanel-postgresql-libs >= 9.0.4 for package: cpanel-perl-524-DBD-Pg-3.5.3-1.cp1162.x86_64
--> Running transaction check
---> Package cpanel-perl-524-DBD-Pg.x86_64 0:3.5.3-1.cp1162 will be erased
---> Package cpanel-php56.x86_64 0:5.6.30-2.cp1164 will be erased
--> Processing Dependency: cpanel-php56 for package: cpanel-php56-XML-Serializer-0.20.2-2.cp1158.noarch
--> Processing Dependency: cpanel-php56 for package: cpanel-php56-XML-Serializer-0.20.2-2.cp1158.noarch
--> Processing Dependency: cpanel-php56 for package: cpanel-php56-XML-Serializer-0.20.2-2.cp1158.noarch
..............................
Transaction Summary
=====================================================================
Remove      173 Package(s)

Installed size: 233 M
Is this ok [y/N]:

 

[cPanelMichael]

Hello @totalchoice,

Thank you for providing an example of a better command to use when checking which remaining PostgreSQL RPMs exist on the system after an incomplete uninstallation. I've edited the original response to remove that command.