doveadm client not compatible with this server (mixed old and new binaries?)
I'm getting the error "doveadm(10.0.0.10): Error: ddoveadm client not
compatible with this server (mixed old and new binaries?)" on the source
server (10.0.05) when trying to sync with a new destination server and I
feel the error seems very obvious and self-explanatory except for one
small thing - both servers claim to be the same version
dovecot -n reports:
Source (10.0.0.5):
2.2.31 (65cde28): /usr/local/etc/dovecot/dovecot.conf
Pigeonhole version 0.4.19 (e5c7051)
OS: FreeBSD 11.1-RELEASE-p1 amd64
Destination (10.0.0.10):
2.2.31 (65cde28): /usr/local/etc/dovecot/dovecot.conf
Pigeonhole version 0.4.19 (e5c7051)
OS: FreeBSD 11.1-RELEASE-p1 amd64
The only difference between the two outputs of dovecot -n are the
mail_replica host (which are set to each other) and the ssl_cert location
(which have their own domain names in the path).
Replication is set to use tcp and the ports and passwords match. I was
wondering if it's something they may depend on but the ones I'm aware
cause most problems in general (libressl-2.5.5 and maridb-client-10.1.26)
match. Any pointers that can be offered would be appreciated because I
feel I'm missing something obvious.
TIA Kevin
I've ran into this after an upgrade of one of my instances. For whatever reason when I restarted the service there was still an old process hanging around.
Fully stopping the service, checking that there were no dovecot processes running, then starting it up again resolved the issue.
If that fails, turning off SSL within your doveadm/plugin blocks temporarily may reveal other errors.
Good luck.
-- Matt Pallissard
On Sat, Aug 19, 2017 at 09:47:35PM +0100, Kevin Golding wrote:
I'm getting the error "doveadm(10.0.0.10): Error: ddoveadm client not compatible with this server (mixed old and new binaries?)" on the source server (10.0.05) when trying to sync with a new destination server and I feel the error seems very obvious and self-explanatory except for one small thing - both servers claim to be the same version
dovecot -n reports:
Source (10.0.0.5):
2.2.31 (65cde28): /usr/local/etc/dovecot/dovecot.conf
Pigeonhole version 0.4.19 (e5c7051)
OS: FreeBSD 11.1-RELEASE-p1 amd64
Destination (10.0.0.10):
2.2.31 (65cde28): /usr/local/etc/dovecot/dovecot.conf
Pigeonhole version 0.4.19 (e5c7051)
OS: FreeBSD 11.1-RELEASE-p1 amd64
The only difference between the two outputs of dovecot -n are the mail_replica host (which are set to each other) and the ssl_cert location (which have their own domain names in the path).
Replication is set to use tcp and the ports and passwords match. I was wondering if it's something they may depend on but the ones I'm aware cause most problems in general (libressl-2.5.5 and maridb-client-10.1.26) match. Any pointers that can be offered would be appreciated because I feel I'm missing something obvious.
TIA Kevin
On Wed, 23 Aug 2017 21:19:33 +0100, Pallissard, Matthew
<dovecot@pallissard.net> wrote:
I've ran into this after an upgrade of one of my instances. For
whatever reason when I restarted the service there was still an old
process hanging around.Fully stopping the service, checking that there were no dovecot
processes running, then starting it up again resolved the issue.
Given I was confident that I always completely stop the service for any
upgrades I confess I was somewhat skeptical about this, but it worked.
I did a full stop of the entire mail system on both machines before
starting them again. Not restart, a stop command followed by a start
command, and looking at the log files I'm no longer getting complaints
about mixed binaries. I'm kicking myself for this one, but also grateful -
thanks for that.
participants (2)
-
Kevin Golding
-
Pallissard, Matthew