[mysql] - read: connection reset by peer

Hello,

After following the doc to install a Pydio server under version 4.0.2 Home version, by making a cell configure via the Web interface and after validating all the options, I have in the last line in the terminal the following error :

[mysql] 2022/10/29 20:52:26 packets.go:37: read tcp <LOCAL_IP_SRV>:49838-><REMOTE_SQL>:3306: read: connection reset by peer

The database is created but the Caddy server crashes.
Has anyone seen this problem before? Maybe the MariaDB timeout?

Thank you.

Looking through all my logs, I do indeed have some similar errors on logs/pydio.log, also related to mysql (I’m also using MariaDB); in my case, however, they’re closing bad idle connection: EOF — not exactly the same (the line of code is 123, not 37).

However, I’m aware that this comes from a lot of tinkering I’ve been doing on my server, attempting to squeeze a bit more performance out of it. More precisely, I am setting short timeouts on idle TCP connections, deliberately so (I was hitting some limits with a completely different and unrelated application, so I changed those settings globally).

I do have MySQL’s interactive_timeoutand wait_timeout both set to 180, but of course the kernel-level sysctl settings will take precedence. Since all my connections to the MariaDB server are local (not remote as seems to be your case), these are actually not ‘true’ TCP/IP connections, but rather Unix sockets ‘disguised’ as Internet sockets for the purposes of complying to a generic TCP/IP API — the kernel will just deal with those specially and outside the regular TCP/IP stack. This, in turn, means that there is no real overhead when dropping connections and re-establishing them again. Obviously, if you are connecting to a remote MySQL/MariaDB server, this doesn’t apply, and you’ll have to tweak those timeouts for your specific setup.

I have no idea if this tutorial is legitimate or just clickbait, but it gives a few interesting ideas on how to track down that kind of error and attempt to fix it:

It’s just basic ideas and generic guidelines, but maybe they might help you out.

Also, in my case, Caddy does not crash. The logged error is harmless (from my perspective).

What seems to be baffling in your case is that the database does get created (meaning that the connection is fine), but, once it’s created, it seems that Cells cannot communicate with it any longer, and the error will be sent upstream to the Caddy component, which will ultimately crash. That is, indeed, a rather strange behaviour, because if your Cells database user is able to create a database and populate it with initial data, it’s rather strange that it cannot access it any more (I mean, it cannot be a ‘simple’ MySQL permissions issue, since if your user has ‘create’ access, it surely has read access as well).

It’s strange how creating a database does not incur in any timeout — that is, after all, an operation requiring a lot of MySQL’s resources — while accessing it (which should be light-weight) drops an error and crashes Caddy! I’m afraid that this is way too strange for me; hopefully some of the experts from the dev/support team are able to shed some light on your issue…

Hi Ascencas_74,

“connection reset by peer” indicates the database closed the connection to the application so it would point to a problem elsewhere. Is it possible to look at the database logs to see if there are any hints there ? Can you also give us a bit of info on the type of servers your are setting your Cells on please (os, ramp, cpu…) ?

What do you mean by “the Caddy server crashes” ? Do you have any logs showing this ?

Thanks,
Greg