Plesk 10 Migration Failure

[KrazyBob]

The most frustrating part of Plesk is upgrading... I have a fresh install of Plesk psa v10.1.1_build1010110120.18 os_CentOS 5 inside Virtuozzo. I have used the command-line method of exporting the content from a Plesk 8.6 server and then scp'd the TAR file over per the usual process. The dump file is on the destination and IP's are available. Here's how th proess is going and failing.

I navigate to the Migration Manager and select a local migration. I indicate the path to the dump file (/root/restoration/dump.xml) and then I see IP mapping that is correct. I click [Continue] and after a brief moment I am returned back to the Tools menu. In my best Scooby-Doo impression -- Harrumph? I navigate back to the migration manager and it tells me that none are running. But yet if I go to Hosting or Customers I can see that each are being added one by one. Returning to the Migration Manager and clicing on [Refresh] shows no change.

I have tried this twice with the same results. I made a copy of the container with a clean Plesk install before starting, so my starting point is fresh.

Waz up? This is the most frustrating part... I have 24 Plesk upgrades to do and this is the first. Harrumph!!! I've been at this for hours and haven't got a clue.

Should I have upgraded to Plesk 9.5? It isn't too late. I love Plesk but after shaiving my head to honor my young daughter with brain cancer I have none to pull out!!!

I humbly thank you.

[breun]

I'd report these failures to Parallels. I have no experience with this migration path. Have you tried running a direct migration instead of first creating an intermediate dump?

Our last attempt to upgrade to Plesk 10 also failed (because of the incompatibility with PHP 5.2 bug, which is apparently fixed now). We might try again when 10.2 is out, but Plesk 9 has been serving us pretty nicely, so we're not in an any hurry.

[KrazyBob]

Thanks for the reply.

I opened a paid ticket with Parallels and it has, well, not been replied to yet. I did upgrade to PHP 5.2.17 first and wonder if I should install Plesk first and then upgrade PHP. The error reports as a Zend error, which is 2.2.0. The exact same error ocurred trying to do a GUI to GUI migration.

Plesk 10.1.1 is also only reporting 1GB of RAM when the container has 2GB assigned to it, and it reports 100GB of HDD space when I have assigned 150GB.

Code: Select all

ERROR: Zend_Db_Statement_Exception
SQLSTATE[HY000]: General error: 1 Can't create/write to file '/tmp/#sql_4e23_0.MYI' (Errcode: 122)


0: Pdo.php:238
        Zend_Db_Statement_Pdo->_execute(array)
1: Statement.php:283
        Zend_Db_Statement->execute(array)
2: Abstract.php:433
        Zend_Db_Adapter_Abstract->query(string 'DESCRIBE `sessions`', array)
3: Abstract.php:230
        Zend_Db_Adapter_Pdo_Abstract->query(string 'DESCRIBE `sessions`')
4: Mysql.php:136
        Zend_Db_Adapter_Pdo_Mysql->describeTable(string 'sessions', NULL null)
5: Abstract.php:696
        Zend_Db_Table_Abstract->_setupMetadata()
6: Abstract.php:722
        Zend_Db_Table_Abstract->_getCols()
7: Abstract.php:762
        Zend_Db_Table_Abstract->_setupPrimaryKey()
8: DbTable.php:517
        Zend_Session_SaveHandler_DbTable->_getPrimary(string 'a97718add54e8940cb895fd2eedb3824')
9: DbTable.php:316
        Zend_Session_SaveHandler_DbTable->read(string 'a97718add54e8940cb895fd2eedb3824')
10: SaveHandler.php:26
        CommonPanel_Session_SaveHandler->read(string 'a97718add54e8940cb895fd2eedb3824')
11: :
        session_start()
12: class.Session.php:150
        Session->Session()
13: auth.php3:183

[breun]

I opened a paid ticket with Parallels and it has, well, not been replied to yet. I did upgrade to PHP 5.2.17 first and wonder if I should install Plesk first and then upgrade PHP. The error reports as a Zend error, which is 2.2.0. The exact same error ocurred trying to do a GUI to GUI migration.

The panel runs on its own internal version of PHP, as far as I know it doesn't use the php-* packages, so that should not make a difference when migrating. (The php-* packages are used for running the websites you host on your server.)

Plesk 10.1.1 is also only reporting 1GB of RAM when the container has 2GB assigned to it, and it reports 100GB of HDD space when I have assigned 150GB.

Does the OS itself report the expected values?

Code: Select all

ERROR: Zend_Db_Statement_Exception
SQLSTATE[HY000]: General error: 1 Can't create/write to file '/tmp/#sql_4e23_0.MYI' (Errcode: 122)

The default permissions on /tmp should allow anyone to write there. Are permissions on /tmp 'rwxrwxrwt' (1777)?

[KrazyBob]

/tmp is fine. This is normal Virtuozzo container and I have Plesk 8.x and 9.x installed just fine.

The OS properly reports both RAM and disc space.

Code: Select all

-bash-3.2# cat /proc/meminfo 
MemTotal:      2097152 kB
MemFree:       1657752 kB

-bash-3.2# df -h
Filesystem            Size  Used Avail Use% Mounted on
vzfs                  150G   43G  108G  29% /
simfs                 150G   43G  108G  29% /tmp
simfs                 150G   43G  108G  29% /var/tmp
tmpfs                 2.0G  4.0K  2.0G   1% /dev
vzfs                  150G   43G  108G  29% /var/named/run-root/var/run/dbus
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/before-local
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/before-queue
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/before-remote
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/info
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/spool

This is something with Plesk 10.1.1. But I am confused about Plesk having its own internal PHP. But I just noticed that Zend doesn't seem to be fully installed. This is a CentOS ez-template and I wonder... I'm not sure how to get Zend updated in the container.

[breun]

But I am confused about Plesk having its own internal PHP.

Plesk 9.5.4 has a php binary at /usr/local/psa/admin/bin/php that is used to run the Plesk panel:

Code: Select all

# rpm -qf /usr/local/psa/admin/bin/php
psa-9.5.4-cos5.build95101209.08.x86_64

AFAIK this was also the case with Plesk 8 and is still the case with Plesk 10.

[KrazyBob]

I believe you, I just didn't know. Thank you.

Code: Select all

-bash-3.2# rpm -qf /usr/local/psa/admin/bin/php
plesk-core-10.10.1-cos5.build1010110120.18

I checked and Zend Optimizer was not installed. I installed it without issue and started a new GUI local migration. After confirming IP mapping it returned me to the Server Tools menu as it has before. I'll know in about an hour if the same Zend error repeats.

I am only using Plesk 10.x to stay current and not waste my SUS fee, which on 25 servers is costly. But I may need to use Plesk 9.5.x if I cannot resolve this. I started years ago with Ensim and migrations have never been kind to me.

[breun]

I checked and Zend Optimizer was not installed. I installed it without issue and started a new GUI local migration. After confirming IP mapping it returned me to the Server Tools menu as it has before. I'll know in about an hour if the same Zend error repeats.

There is no need to install Zend Optimizer, at least not for Plesk itself.

[KrazyBob]

Please note the previous Zend errors reported when the migration failed.

Code: Select all

0: Pdo.php:238
        Zend_Db_Statement_Pdo->_execute(array)
1: Statement.php:283
        Zend_Db_Statement->execute(array)
...

[breun]

Zend does not necessarily have anything to do with Zend Optimizer, and I don't believe it does in this case. The engine in PHP is also called Zend. (And there is the company Zend behind PHP, Zend Framework, Zend Studio, etc.) Also, the Zend Optimizer you installed is probably installed as an extension to the php-* installation, which is not used by Plesk (it has its own separate PHP engine).

The root cause of the problem you posted seems to be that writing to a file in /tmp failed. I have no idea why that failed (the error message doesn't say).

[KrazyBob]

The migration attempt failed even after making sure that Zend Optimizer was installed. I only assumed Zend because it was reporting an error. It's bed time. I have two feet of snow in front of the door and, well, bed time.

[paulie]

Hi,

Your error isn't Zend related, Zend is just having a fit because of MySQL erroring. If, as breun asked, /tmp is fine and fully writable (and it'd be amazing if it wasn't) try the mysql log file : /var/log/mysqld.log

I doubt it will be much use but there's a possibility of an explanation as to why it couldn't created that temp table/index. Whats worrying is that the SQL error code 122 is usually lack of disk space...whats simfs btw?

Paul.

[KrazyBob]

There is plenty of disc space allocated. Creation of this container has been no different that for Plesk 8 or 9 and the only variable is Plesk 10.

Code: Select all

-bash-3.2# df -h
Filesystem            Size  Used Avail Use% Mounted on
vzfs                  150G   43G  108G  29% /
simfs                 150G   43G  108G  29% /tmp
simfs                 150G   43G  108G  29% /var/tmp
tmpfs                 2.0G  4.0K  2.0G   1% /dev
vzfs                  150G   43G  108G  29% /var/named/run-root/var/run/dbus
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/before-local
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/before-queue
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/before-remote
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/info
tmpfs                 2.0G     0  2.0G   0% /usr/local/psa/handlers/spool

Still no response from Parallels support...

[Highland]

What you're looking at is a stack trace produced by Zend Framework (which it appears that Plesk now uses). All ZF stuff uses classes that start with Zend_

In your case, the stack trace isn't the problem. This is your problem, a MySQL error

ERROR: Zend_Db_Statement_Exception
SQLSTATE[HY000]: General error: 1 Can't create/write to file '/tmp/#sql_4e23_0.MYI' (Errcode: 122)

Is there a file conflict in /tmp?

[paulie]

Hi Bob,

One possibility is that MySQL can't write to your /tmp directory because of the way its mounted, I've had this happen to me in the past when I've mounted /tmp on a tmpfs. Unfortunately the quickest/easiest solution to test this would be to reboot remounting /tmp back on the main file system , alternatively you could reconfigure MySQL to write to a directory on the main partition.

Paul.