 |
Update: when it reaches max (mysql) errors, mysql is unreachable by SOGo and other applications like Postfix/Dovecot. |
 |
Which SOPE Version do you use? |
|
|
It's sope4-4.0.4. Installed from FreeBSD ports tree too. |
|
|
Dear developers, Any update? This issue drives all FreeBSD users crazy. :( |
|
|
Also seeing the same issue since upgrading to FreeBSD 12.0-RELEASE and MySQL 5.7.25 client and server installed from ports. Haven't yet detected any pattern to the frequency of MySQL becoming unreachable. A very kludgy workaround is a little script that monitors the MySQL error log and restarts the database whenever the "Bad handshake" message count increments -- but that really is a hack. The system has plenty of CPU, memory, disk, etc., and there's no apparent reason why MySQL should lock up. It ran OK on previous versions of FreeBSD. |
|
|
I confirm the same problem on FreeBSD 11.2. |
|
|
Any word on a fix for this? Nine months later, the error is still present with FreeBSD 12.1-RELEASE-p1, sogo 4.1.1 and sope 4.1.1 installed from ports. |
|
|
I have the same problem on newly released Debian 10. Would appreciate any help from the devs :) |
|
|
It happens on a Ubuntu 18.04.4 box too. |
|
|
Today i found it happens on a Ubuntu 16.04 box too. |
|
|
The problem continues in Sogo 4.3.1 on Debian 10 |
|
|
Same problem found in CentOS 8 running SOGo 4.3.2 with MariaDB 10.3. This is really unacceptable that the issue has been present for so long without being paid attention to, as it requires frequent restarts of the database server to keep up with the absurd amount of errors. |
 |
Which one of the 3 "sogo-tool" commands being ran cause the error count to increase? |
|
|
No way to tell. Given the frequency they run at (every minute) and the incrementing rate of failed connections, all three. I've run each command manually on the CLI and verified that their output (with the --verbose flag) works after redirecting output to stdout. Nothing unusual in the output, commands seem to be "working" but the mysql errors continue. In addition, my sogo.log is filled with warnings like this (just an excerpt, there are literally thousands in the log): Jul 09 16:21:06 sogod [1257]: [WARN] <0x0x55cb83720ef0[WOWatchDogChild]> pid 196061 has been hanging in the same request for 6 minutes I've matched some of these PIDs to the ones spawned by the sogo-tool cron jobs, so there appears to be a correlation. Band-aid solution is to restart the database server, change the error limit, or disable the cron jobs, but the issue itself is just plain bizarre, especially given that by and large, SOGo still "works" and the commands execute properly on the sogo-tool side. TL;DR -- all three commands cause the error count to increase, to the best of my knowledge. |
|
|
The hanging pid has nothing to do with sogo-tool - those are from EAS clients and perfectly normal. |
|
|
Understood. Can rule out log content from relevance then. Nothing else is out of place in sogo.log, and as mentioned, the commands execute properly, but the mysql server still hangs up on the connections, by rate of frequency, seemingly all three commands. |
|
|
Can you confirm by how many the error rate increases when you run a command manually? and which one you run. |
|
|
hi @ludovic, Each time i ran the command (any of them), it caused one MySQL error. |
|
|
@ludovic I've done a good deal of further testing, and interestingly enough, my issue actually isn't exclusively caused by sogo-tool. However, I was able to CONFIRM that all three above commands increment the error rate, by one instance of the error each. I assumed it was limited to sogo-tool because of the pre-existing issue and error code, but after disabling my cronjobs containing the above sogo-tool commands, I found that my mariadb logs were still filled with the error message. The sogod service itself is also triggering this error, I have verified this by disabling the service and manually running the same command it does (using sudo to runas the sogo user): /usr/sbin/sogod -WOWorkersCount 10 -WOPidFile /var/run/sogo/sogo.pid -WOLogFile /var/log/sogo/sogo.log This command also results in the mysql error, at a staggering frequency since sogod runs this command so often. It seems to do so at a rate of about 10 per minute (would make sense -- 10 workers), which is why the errors stack up so quickly for me. I'm restarting mariadb once daily, any less frequently and the database isn't able to keep up. Before you ask -- yes selinux is disabled, and there are no other issues on the machine. So, on my machine, the error is triggered by any execution of "sogo-tool" or "sogo-ealarms-notify" or "sogod." |
- Anonymous
