burnley
Regular Pleskian
Plesk 12.5.30 on CentOS on both source and target server, using migrator 2.7.9. I see the latest is 2.8.7 so I might have to look into it later down the track.
I think we have an issue which has been plaguing us recently. Some domains fail to migrate, causing the deployer process to loop for a long time, read *hours* before bailing out. Looking into the migration rsession logs I've found this error interesting (personal data obfuscated):
[2017-06-14 08:58:32.331|19576] INFO: Request is ready for: PMM_PROFILE_LOG=/usr/local/psa/PMM/rsessions/20170614074441590/profile.log PLESK_RESTORE_MODE=1 PLESK_DISABLE_PROVISIONING= LANG=en_US.UTF-8 ALLOW_WEAK_PASSWORDS= /usr/local/psa/admin/plib/api-cli/turboaddr.php '-c' '69c30770aa10566bb73c6f067c43b2c4' '-owner-email' '[email protected]' '-type' 'object' '-home-phone' '' '-fax' '' '-title' '' '-mobile-phone' '0123 456 789' '-company' 'Company Name' '-email' '[email protected]' '-alias' '' '-notes' '' '-work-phone' '(02) 1234 5678' '-ignore-nonexistent-options'
[2017-06-14 08:58:34.619|19576] INFO: HTTP status code is: 500
[2017-06-14 08:58:34.620|19576] INFO: ExecCliGate::InternalServerError[f9fa694d-364f-4780-8a43-7782cb7b3235]: Internal server error: <cli><failure>MySQL query failed: Table 'horde.turba_objects' doesn't exist</failure></cli> [./cmd_exec.cpp:344]
On the target Plesk server, which is a brand new installation, we don't have Horde webmail installed, just Roundcube. I went and manually created horde database and restored the SQL dump fetched from the source onto the target and this appears to have fixed the loop, shortly after the the migration resumed and log entries started to appear again in the info.log file.
Looks like a bug to me, where a command which shouldn't be executed - /usr/local/psa/admin/plib/api-cli/turboaddr.php - returns 500, which causes the loop.
Does this problem still exist in the latest Panel migrator?
I think we have an issue which has been plaguing us recently. Some domains fail to migrate, causing the deployer process to loop for a long time, read *hours* before bailing out. Looking into the migration rsession logs I've found this error interesting (personal data obfuscated):
[2017-06-14 08:58:32.331|19576] INFO: Request is ready for: PMM_PROFILE_LOG=/usr/local/psa/PMM/rsessions/20170614074441590/profile.log PLESK_RESTORE_MODE=1 PLESK_DISABLE_PROVISIONING= LANG=en_US.UTF-8 ALLOW_WEAK_PASSWORDS= /usr/local/psa/admin/plib/api-cli/turboaddr.php '-c' '69c30770aa10566bb73c6f067c43b2c4' '-owner-email' '[email protected]' '-type' 'object' '-home-phone' '' '-fax' '' '-title' '' '-mobile-phone' '0123 456 789' '-company' 'Company Name' '-email' '[email protected]' '-alias' '' '-notes' '' '-work-phone' '(02) 1234 5678' '-ignore-nonexistent-options'
[2017-06-14 08:58:34.619|19576] INFO: HTTP status code is: 500
[2017-06-14 08:58:34.620|19576] INFO: ExecCliGate::InternalServerError[f9fa694d-364f-4780-8a43-7782cb7b3235]: Internal server error: <cli><failure>MySQL query failed: Table 'horde.turba_objects' doesn't exist</failure></cli> [./cmd_exec.cpp:344]
On the target Plesk server, which is a brand new installation, we don't have Horde webmail installed, just Roundcube. I went and manually created horde database and restored the SQL dump fetched from the source onto the target and this appears to have fixed the loop, shortly after the the migration resumed and log entries started to appear again in the info.log file.
Looks like a bug to me, where a command which shouldn't be executed - /usr/local/psa/admin/plib/api-cli/turboaddr.php - returns 500, which causes the loop.
Does this problem still exist in the latest Panel migrator?