dovecot - Aug 2017 - 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 at 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.