1

I have been struggling with this issue for over a year now, and it’s really giving me a headache.

I often experience I am unable to connect to the MySQL server through SequelPRO. If I ssh into the server, I can use mysql fine, see processes, etc. My web app works fine too.

When I try to SSH into my MySQL database through Sequel PRO, this message appears instantly:

Unable to connect to host 127.0.0.1, or the request timed out. Be sure that the address is correct and that you have the necessary privileges, or try increasing the connection timeout (currently 10 seconds). MySQL said: Lost connection to MySQL server at 'reading initial communication packet', system error: 0

ONLY solution is to reboot the server. Sometimes I’d reboot the server, and it still won’t work. After a few reboots it works. But usually it works every time.

  • It happens on all my different forge servers (php5 & php7) and has happened since day one.
  • Restarting the mysql server (like sudo service restart mysql) does not work
  • It happens on different networks (wifi, local, etc)
  • I can connect fine from another mac with different SSH-key (same OSX and Sequel Pro build). I have even tried copying my own SSH key to the other computer, and logging on through that. That works fine as well.
  • I happens at random times, often if my Sequel Pro was open when my mac when to sleep (but not always - sometimes I can open it 24 hours later, and still be connected). But all of a sudden, I’d be disconnected, and when I try to login again, it see the following error:
  • In some situations, I can login again to MySQL through sequel pro, even though I did not do anything (i.e. reboot server).

The way I connect:

MySQL Host: 127.0.0.1 Username: something Password: something Port: 3306 SSH Host: server-ip SSH User: something SSH Key: path to my id_rsa SSG Port: default/not-set

Any ideas?

My Sequel Pro version: v1.1 build 4499 My OSX: OS X El Capitan v 10.11

Server: Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-71-generic x86_64)

MySQL: Ver 14.14 Distrib 5.7.10, for Linux (x86_64) using EditLine wrapper

Improve this question
2
  • 2
    Are this MySQL server a busy one? Can you share the output of the commands: show status like '%thread%; and show status like '%conn%'; ?
    – fgbreel
    Jan 31, 2016 at 21:27
  • 1
    Have you tried opening an SSH connection (outside of Sequel Pro) with a tunnel to port 3306 and then using Sequel Pro to connect to localhost:[yourtunneledport]?
    – Dominic O'Connor
    Feb 2, 2016 at 14:58

4 Answers 4

Reset to default
0

Looks like you're having issues connecting through SSH or maintaining the SSH tunnel, these errors are usually reported to /var/log/auth.log. Probably SequelPRO tries to use a connection that is no longer available, stalled.

You may also try to manually set the SSH tunnel: http://www.sequelpro.com/docs/Set_up_an_SSH_Tunnel — if this works, then it's surely a bug/problem with SequelPro SSH connection.

Improve this answer
0

The mention of 127.0.0.1 sounds like you are using the SSH tunnelling feature of SequelPro.

See How to reliably keep an SSH tunnel open for solutions to this problem.

You can be certain this issue issue if the next time it happens, you disconnect your SSH session to the server, re-connect, and it works.

Improve this answer
0

Bit of a shot in the dark but I've seen this before and managed to debug it.

Its a real bizarre edgecase though.

If your clocksource is set to jiffies certain processors do not stay in sync with one another, leading to a situation where the time on one processor differs from the time on another processor. It can be out be a difference of only 1 second for this to cause a problem in mysql.

You can test for this by doing:

for i in $(seq 0 $(($(getconf _NPROCESSORS_ONLN)-1))); do taskset -c $i date & done

Each line should report the same result, certainly not a second out. You should try it a few times to make sure you just didnt cross a 1 second threshold during the test.

The bug I came across here was that one processor was 1 second out from the other processor. This lead to a condition where mysql would ask for the time, then compare the time again with the next new request (which was -1 second away). Given this is unexpected it would underflow and mysql thought the connection was four billion seconds older than what it was.

If this is the problem, you should change the clocksource on the host from jiffies to tsc, hpet or acpi and the problem should go away.

Improve this answer
-1

Set your ~/.ssh/config to include 'ForwardAgent yes'. Also grant all on db.* to 'user'@'127.0.0.1' identified by 'password'

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .