• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

[PPP-17717] Unable to get server IP. Error: Client: unable to select: no such row in the table

Shane Corgatelli

New Pleskian
Hi,

When attempting to add a new slave using the Slave DNS Manager extension I get the error in the subject.
The error seems similar to other 'Client: unable to select' errors documented in the forums and I have tried the check_db.php script (which doesn't work at all) and the check_db_integrity-beta.php script (which does give some errors, but I'm not sure what they mean). What is going on?

Plesk: 12.0.18 Update #64
OS: CloudLinux Server 6.6 (Leonid Kizim)
Extension Version: 1.4

Here's the contents of the log file:

[2015-09-17 12:22:17] ERR [panel] Unable to get server IP. Error: Client: unable to select: no such row in the table:
0: Rndc.php:16
Modules_SlaveDnsManager_Rndc->getServerIP()
1: IndexController.php:49
IndexController->addAction()
2: Action.php:516
Zend_Controller_Action->dispatch(string 'addAction')
3: Standard.php:295
Zend_Controller_Dispatcher_Standard->dispatch(object of type Zend_Controller_Request_Http, object of type Zend_Controller_Response_Http)
4: Front.php:954
Zend_Controller_Front->dispatch()
5: Application.php:66
pm_Application->run()
6: index.php:6
[17-Sep-2015 12:22:17 America/Chicago] pm_Exception: Unable to get server IP. Error: Client: unable to select: no such row in the table
file: /usr/local/psa/admin/plib/modules/slave-dns-manager/library/Rndc.php
line: 16
code: 0
trace: #0 /usr/local/psa/admin/plib/modules/slave-dns-manager/controllers/IndexController.php(49): Modules_SlaveDnsManager_Rndc->getServerIP()
#1 /usr/local/psa/admin/externals/Zend/Controller/Action.php(516): IndexController->addAction()
#2 /usr/local/psa/admin/externals/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('addAction')
#3 /usr/local/psa/admin/externals/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#4 /usr/local/psa/admin/plib/pm/Application.php(66): Zend_Controller_Front->dispatch()
#5 /usr/local/psa/admin/htdocs/modules/slave-dns-manager/index.php(6): pm_Application->run()
#6 {main}​


Thanks for your help,
Shane
 
These scripts are very outdated and I would not recommend to use them. In latest Plesk 12.5 version we have implemented repair tool for fixing database inconsistencies.
As far as I see this issue is really caused by some kind of database inconsistency. I suggest you contact Odin Support Team for fixing it directly on your server.
 
I've got a work-around. I've been signing-in using an 'Additional Administrator' account. However, when I sign-in using the admin account adding a new slave works fine. This sounds like a bug to me.

When using a 'Additional Administrator' account the relevant lines from the debug log are:

[2015-09-23 17:26:39] DEBUG [dbquery] [15] SQL: SELECT `clients`.* FROM `clients` AS `clients` WHERE (`type` = 'admin')
[2015-09-23 17:26:39] DEBUG [dbquery] [15] END: 0.0003199577331543 sec
[2015-09-23 17:26:39] DEBUG [dbquery] [16] SQL: select `id`, `parent_id`, `vendor_id`, `type`, `cr_date`, `cname`, `pname`, `login`, `status`, `phone`, `fax`, `email`, `address`, `city`, `state`, `pcode`, `country`, `locale`, `description`, `limits_id`, `perm_id`, `pool_id`, `logo_id`, `external_id`, `overuse`, `account_id`, `guid` from `clients` where `id`=1
[2015-09-23 17:26:39] DEBUG [dbquery] [16] END: 0.00033807754516602 sec
[2015-09-23 17:26:39] DEBUG [dbquery] [18] SQL: SELECT `admin_aliases`.* FROM `admin_aliases` AS `admin_aliases` WHERE (((`admin_aliases`.`id` = 3)))
[2015-09-23 17:26:39] DEBUG [dbquery] [18] END: 0.00020599365234375 sec
[2015-09-23 17:26:39] DEBUG [dbquery] [39] SQL: select `id`, `parent_id`, `vendor_id`, `type`, `cr_date`, `cname`, `pname`, `login`, `status`, `phone`, `fax`, `email`, `address`, `city`, `state`, `pcode`, `country`, `locale`, `description`, `limits_id`, `perm_id`, `pool_id`, `logo_id`, `external_id`, `overuse`, `account_id`, `guid` from `clients` where `id`=3
[2015-09-23 17:26:39] DEBUG [dbquery] [39] END: 0.00039315223693848 sec

Note that it is trying to query a client, which is not found, with the same id (3) as the admin_alias.

When using the admin account the log shows:

[2015-09-23 17:30:16] DEBUG [dbquery] [15] SQL: SELECT `clients`.* FROM `clients` AS `clients` WHERE (`type` = 'admin')
[2015-09-23 17:30:16] DEBUG [dbquery] [15] END: 0.0003819465637207 sec
[2015-09-23 17:30:16] DEBUG [dbquery] [16] SQL: select `id`, `parent_id`, `vendor_id`, `type`, `cr_date`, `cname`, `pname`, `login`, `status`, `phone`, `fax`, `email`, `address`, `city`, `state`, `pcode`, `country`, `locale`, `description`, `limits_id`, `perm_id`, `pool_id`, `logo_id`, `external_id`, `overuse`, `account_id`, `guid` from `clients` where `id`=1
[2015-09-23 17:30:16] DEBUG [dbquery] [16] END: 0.00034403800964355 sec

I've attached the full log files for both cases.

Thanks,
Shane
 

Attachments

  • plesk_admin_alias_log.txt
    8.8 KB · Views: 1
  • plesk_admin_log.txt
    10.9 KB · Views: 0
Hi @Shane Corgatelli!

Thank you for reporting the issue. It's not an inconsistency in your database. I confirm that it's bug with ID PPP-17717 in our internal tracker. I hope it'll be fixed in nearest microupdates for Plesk 12.5.

The only workaround is to use admin account instead of additional admin to manage Slave DNS.
 
Back
Top