• 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.

Resolved Migration failed - rsync error: timeout in data send/receive (code 30) at io.c(195) [sender=3.1.2]

Matt N

New Pleskian
Hi All,

I am attempting to perform a migration, which is failing with the following error:

Failed to fetch basic information about resellers, clients and domains data from source servers
Cause: Command execution failed on the local server with non-zero exit code.
command: rsync -r --chmod=Fu=r,Du=rwx,go= --timeout=30 -e 'ssh -i /usr/local/psa/var/modules/panel-migrator/sessions/20190525230410/ssh-keys/id_rsa.123.45.67.89 -p 22 -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o GSSAPIAuthentication=no' /usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/plesk/source/legacy/extras/plesk_17_0_pmm_shared/ root@123.45.67.87:/tmp/migrate/plesk_migrator-wuxrm9m2601kfpywebkhf8gec1z3ylk6/pmm_agent
exit code: 30
stdout:
stderr: [sender] io timeout after 30 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(195) [sender=3.1.2]
That is a critical error, migration was stopped.

the debug log, contains a stack more detail - I can see that the migration is:

  • able to collect to the source server
  • able to transfer ssh keys
  • create appropriate folders on source server

Details of the servers :

Destination

Plesk Onyx 17.8.11 MU #54
running on CloudLinux 7.6
1 TB disk space, with over 850GB free
32 GB RAM

Source

Plesk Only 17.8.11 MU #54
running Centos 7.6.1810
1 TB disk space, with over 800GB free
8 GB RAM
running SELinux (tried with both "enforcing" and "permissive" modes)


Destination server is brand new, has only had the following actions performed:

  • Centos 7 installed
  • CloudLinux Installed
  • Plesk Installed
  • basic Plesk config done, such as:
    • adding IP addresses
    • setting up Firewall, Fail2Ban, ModSecurity
    • SSL/TLS certs added
    • upgrade of Mysql 5.5 to MariaDB 10.2 (source has MariaDB 10.1)
    • configured HTTP/2 etc (basically, done all the important stuff in Advisor)
    • Set system time etc.

Really hoping for some suggestions/ideas - before I have to reach out to the Plesk Reseller for support, or to Plesk directly (which I then have to pay for).
 
Last edited:
It seems that the source server is not responding while rsync is running within the timeout windows of 30 seconds. As far as I know it is not possible to change the timeout value by a Plesk configuration file (there are options for migrator, but not the rsync timeout). I would like to suggest to first check that the load on the source system is low when you do a migration. Then, you could try to do the migration step by step, for example first create the accounts only, then run migrator again and only transfer the databases, then the files, then the mails etc. all in separate transactions. This could help to avoid long waiting times.
 
Thanks Peter far the suggestions..
While doing some further testing and research, I found that my rsync from my one of my Centos boxes in my home lab to the source server was also slow when attempting to make just an ssh connection as well (I had never paid much attention to the SSH speed, as I scripted the login with my client).

I found from lots of googling, that if you set the following entry in the /etc/ssh/sshd_config file

Code:
UserDNS no

(if the setting exists as either a Yes, or no with a #, then remove the #, and change to no, then restart the SSH daemon with :

Code:
service sshd restart

magically resolved the issue..
 
Thank you the post. Great that you have found out that the slow speed is caused by slow name resolution. Thank you for providing the workaround for this, too.
 
not a problem at all! forums are a LOT more useful when they have suggestions, and when something fixes it, a resolution! :) nothing worse than people coming back saying 'Fixed it' but not leaving answers for anyone else having the same problem :)
 
I had the same problem with an Debian Stretch Onyx 17.x system as source.
That was the right hint.
Please note that the command has a small spelling error, the right command is: UseDNS no (without "r")
 
Thanks Peter far the suggestions..
Code:
UserDNS no
(if the setting exists as either a Yes, or no with a #, then remove the #, and change to no, then restart the SSH daemon

Strange.
From man 5 sshd_config:
Code:
     UseDNS  Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name
             for the remote IP address maps back to the very same IP address.

             If this option is set to no (the default) then only addresses and not host names may be used in
             ~/.ssh/authorized_keys from and sshd_config Match Host directives.
So UseDNS=No should be the default.
What OpenSSH version do you have?
 
Back
Top