Plesk Migrator omits important settings, gets others wrong, FPM

[TimReeves]

Hi all,

I recently migrated a complete Server via Plesk. OS on both sides Ubuntu 14.04.3, Plesk latest on both sides. So it should be straightforward, right? Er, nope...

Some - for me - crucial "per website" settings are NOT migrated:

1. PHP Settings | Additional configuration directives
2. Apache & nginx Settings | Additional nginx directives

so I ended up e.g. without the additional PHP-Settings to use Redis as session server, not to mention that my own Nginx-Config file was not referenced, so some domains did not work at all.

Also, subscription PHP-Settings defaults were falsely migrated - I got the values from an "owncloud" subdomain as Default values for all domains in the subscription, which is absolutely not what I wanted, as "owncloud" has some very large PHP values compared to all other domains.

Furthermore, one of the PHP-FPM Instances would not start:
| - error: An error occurred, when restoring hosting settings:
| Internal server error: phpinimng failed: invoke-rc.d: initscript plesk-php70-fpm, action "status" failed.
| Service plesk-php70-fpm is down after attempt to restart it

I have 3 different PHP-FPM Instances running (OS-Vendor, 5.6 and 7.0) for various good reasons. For two domains, one of which was migrated in "suspended" state, the Migrator created pool-configs twice, once in OS-Vendor and once in PHP 5.6. Obviously that blocks one instance as they would use the same socket.

I have already highlighted this sort of problem in this thread. I really must re-iterate what I noted there: If PHP support is turned off on a domain, for any reason, then there should not be any pool config created or left lying around for it. That's asking for trouble, and indeed causes trouble, e.g. when calling "/usr/local/psa/bin/php_settings -u" reinstates them, or as here for the Plesk migrator. I think we are talking about a need to change the paradigm here. I've repeatedly had trouble with extraneous pool configs causing sockets to be in use.

@IgorG @trialotto @custer Help Help!

I would have noted these issues directly as a bug report, but the previous address for that, http://www.odin.com/support/plesk/bugreport/ does not exist any more...

Last not least, I have noticed that when Plesk PHP gets updated automatically, in a nightly update run, then FPM instances are not restarted. So Plesk GUI tells me I now have e.g. 5.6.18, but due to no restart actually 5.6.17 is still in service.

Cheers and thanks,

Tim

 

[trialotto]

@TimReeves

As far as possible, I will reply to your post, by quoting some relevant text and commenting on it (in the order "quote" > "comment").

I have 3 different PHP-FPM Instances running (OS-Vendor, 5.6 and 7.0) for various good reasons. For two domains, one of which was migrated in "suspended" state, the Migrator created pool-configs twice, once in OS-Vendor and once in PHP 5.6. Obviously that blocks one instance as they would use the same socket.

No, not really, the pool configs are just "there", the socket is only used by the active PHP.

It is just having a ready-steady template, allowing you to (instantly) switch from PHP version to PHP version, while still having php-fpm enabled. This is normal.

I have already highlighted this sort of problem in this thread. I really must re-iterate what I noted there: If PHP support is turned off on a domain, for any reason, then there should not be any pool config created or left lying around for it. That's asking for trouble, and indeed causes trouble, e.g. when calling "/usr/local/psa/bin/php_settings -u" reinstates them, or as here for the Plesk migrator. I think we are talking about a need to change the paradigm here. I've repeatedly had trouble with extraneous pool configs causing sockets to be in use.

You emphasize the presence of pool configs and, in essence, this emphasis is not correct: pool configs are just present, to become effective when a specific PHP is activated.

That is all. No worries!

Furthermore, the usage of php_settings is a little bit "troublesome": you should not do that to activate specific php settings, as defined in a php.ini.

After all, the -u flag updates the domain-specific PHP settings in accordance to the server-wide php.ini file.

In short, be careful when using the -u flag or, even better, do not use it at all.

Last not least, I have noticed that when Plesk PHP gets updated automatically, in a nightly update run, then FPM instances are not restarted. So Plesk GUI tells me I now have e.g. 5.6.18, but due to no restart actually 5.6.17 is still in service.

This is an indication that something has gone wrong in the past, most likely with configuration and/or installation, with issues not being resolved properly.

The best thing to do is a purge and reinstall of packages: the autoinstaller will not help (i.e. a huge probability that some or more issues remain present).

That is, an apt-get purge and apt-get install command (since you have an Ubuntu OS).

It can do no harm to run a apt-get update after the purge command (and before the install command), I would recommend that "step".

Some - for me - crucial "per website" settings are NOT migrated:

1. PHP Settings | Additional configuration directives
2. Apache & nginx Settings | Additional nginx directives

so I ended up e.g. without the additional PHP-Settings to use Redis as session server, not to mention that my own Nginx-Config file was not referenced, so some domains did not work at all.

Ehm, well, this is quite logical if the files are not in the "right place" and, in all other cases, it is quite strange.

To illustrate, a Redis module is non-default and will have to be copied/rsynced manually.

However, again to illustrate, the custom Nginx directives should be transferred with domains, unless you have put them in the wrong place (for instance, somewhere in /etc/nginx).

Note that it would seem rather convenient if migration processes do transfer certain config files, but it is rather unpractical: this would overwrite config files on the target server, often resulting in a troublesome termination of the migration process or even a complete system breakdown on the target server.

Furthermore, one of the PHP-FPM Instances would not start:
| - error: An error occurred, when restoring hosting settings:
| Internal server error: phpinimng failed: invoke-rc.d: initscript plesk-php70-fpm, action "status" failed.
| Service plesk-php70-fpm is down after attempt to restart it

I am not sure what causes this, but it should not be occurring.

You can check whether the php-fpm is running by going to "Tools & Settings > PHP settings" and "7.0.x FPM application" should be in the list with a green icon before it.

Note that it should be version 7.0.3, otherwise some micro-update (#22) has gone wrong.


In conclusion, I would strongly recommend to do an apt-get purge, update and install sequence for the troublesome PHP versions.

If you want me to, I can talk you through it.

Regards.....

 

[TimReeves]

Many thanks to @trialotto for the substantial reply. Last things first: I keep a clean and up-to-date Server, apt-get purge found 0, update and upgrade also nothing to do, as I very recently upgraded due to the glibc issue.

Somehow I get the feeling like we had this conversation, in tenor, before.

No, not really, the pool configs are just "there", the socket is only used by the active PHP.

Well as I wrote, I have 3 different PHP-FPM Instances all running (OS-Vendor, 5.6 and 7.0) for various good reasons. Tell truth it's in fact 4, the 4th is a self-compiled PHP7 tailored exactly for ownCloud. The point is, PHP7 is fine for WordPress, real fast; but many other popular packages - things like WHMCS, Social Engine, arpReach etc. etc. - a lot of them are not yet ready for PHP7, so I also need a PHP5.6. And then there's the question of INI-Settings which are settable only PHP_INI_SYSTEM, like opCache settings, which can thus only be set once for all FPM pool members using that particular version of PHP. Since I don't want one HUGE opCache area being shared by all sorts of PHP programs on the server, I resort to selecting similar types of Domain-Software to share the same version of PHP with its respective SYSTEM ini settings.

You write "the active PHP" as if there would only be one. My problems with Plesk and PHP all arise from the real-life scenario that I have several active in parallel, which Plesk allows no problem, so Plesk, I feel, should also make sure the setup then works...

After all, the -u flag updates the domain-specific PHP settings in accordance to the server-wide php.ini file.

In general I find this call neccessary. I always use an own "php.ini" file in the system/{domain}/conf directory to tailor the instance of PHP-FPM, e.g. the model used, number of spare servers etc. And when I need to modify that, then, as the handbook says, this call is needed to re-generate the PHP settings. It works fine, in my experience - EXCEPT that it generates a pool config for every domain, even those without PHP support, suspended or disabled. I really feel that this is a major source of problems, not to mention sometimes resource wastage - because then the fact of at least one pool config being present means that PHP-FPM instance will be started. Anyway, normally the pool config has siblings and the FPM master process must be started anyway. Now imagine I suspended a domain with the dynamic FPM model and lots of spare child processes - they will actually be created as processes, although the domain is suspended. That can't be right!

Ehm, well, this is quite logical if the files are not in the "right place" and, in all other cases, it is quite strange.

Well the files being referenced under "Apache & nginx Settings | Additional nginx directives" are located under their respective domain roots, and do get migrated. Just the include statement linking them in gets lost. Re redis: Obviously it's my responsibility to create the basis for referencing redis at the new server, which I did. There are many other things I also have to do on a new server at OS level before starting a Plesk migration, a great many. And I do them. THEN I start a full Plesk migration, and having done my homework, it would be nice if things worked afterwards. I re-iterate, during the migration - over a dozen domains - NO "PHP Settings | Additional configuration directives" or "Apache & nginx Settings | Additional nginx directives" were migrated.

Note that it would seem rather convenient if migration processes do transfer certain config files, but it is rather unpractical: this would overwrite config files on the target server, often resulting in a troublesome termination of the migration process or even a complete system breakdown on the target server.

I absolutely agree with that. As noted, I do all my OS-Homework first, and then expect Plesk to migrate the subscriptions and domains 1:1. To summarise my observations:

1. Extraneous FPM pool configs can be created at the target server, causing some FPM master processes not being able to be started (scenario: several PHP versions in use in parallel)
   
2. "PHP Settings | Additional configuration directives" and "Apache & nginx Settings | Additional nginx directives" are not migrated.

Hope this helps to clarify the situation. Thanks again!

Tim

 

[DerDanilo]

I know that this thread is very old. Still we just have had the same problem that the "Additional Apache directives" as well as the "Additional nginx directives" were not migrated via the Plesk migrator. We set those via GUI and did not change anything via cli or out of the gui.

This happened from Plesk 11.x to 12.x as well as recently from Plesk 12.x to 17.5.

@IgorG
Why aren't those changes migrated? Are they supposed not to migrated?
This caused us a lot of trouble, as we have had to go through every domain and subdomain to check for custom changes.

Our preffered way to move to a new server is not transfering the whole machine (VM), we rather use the Plesk migrator as this seems the cleanest way to migrate.

We have to migrate several machines soon again and would be happy if we could solve this issue till then.

Thanks!

 

[IgorG]

Please check this thread - Issue - Plesk Migrator 12.5 to Onyx