We cannot reproduce (not with 5.21 or 5.22 RC3) and need more information.
1) Please let us see the
Code:
..
..
..part of the job/XML file (fake details that you don't want to make public, or create a ticket and attach there)
2) Is it a 'freshly generated' jobfile or an old one generated with an earlier version? Was it generated using the GUI?
3) Is it only Migration jobs that give this problem? Try for instance a Notifications job with the same details (.. section). Just try to execute the SQL “SELECT 'this is a test'” for instance!
The relation between the two is that it is (or should be) exactly the same code that establishes connection in either case. Actually they are both compiled from the same soruce files, classes and functions. You are pefrectly sure that you use the same jobfile (use FULL path enclosed in “doublequotes” to be sure like
Thanks for confirming that SJA should be able to establish the ssh tunnel. I believe I've found the cause.
I had restricted the SSH user account on the Linux box by setting its shell to /usr/sbin/nologin. I've tried both /bin/false and /usr/sbin/nologin and the results are the same. This seems make the SSH tunnel establishment a bit unreliable. It is clearly working sometimes, and definiately failing at others. Changing the SSH users' shell to /bin/bash seems to fix the problem, but creates a bit of a security hole.
I have a slow (128kbps) uplink which may be contributing to the problem.
If anyone can confirm that a /bin/false shell should work for SSH tunneling into a Linux mysql server, I would appreciate knowing this works for others.