• The exabgp.conf syntax changed, but the documentation didn't
  (exabgp.conf(5)). No "group" at outer layer anymore. Apparently,
  nobody took the hint to "please keep this updated" and "please make
  this reasonably complete" when I submitted it earlier.
  Also, ExaBGP 4 did not complain when I asked it to validate the old 3.4-based configuration file(!)

• Running with

[exabgp.daemon]
daemonize = true

[exabgp.log]
destination = syslog
short = true
level = WARNING

and adding the new

[exabgp.api]
ack = false

because I use the healthcheck module and I don't think it consumes any input, I earlier got only

Sep 18 19:09:54 oliven -: healthcheck-resolver[17649]: send announces for EXIT state to ExaBGP

in the log. Nothing else.

Commenting out "daemonize" and "destination" and running with -d gets more detailed information: it turns out that /var/run/exabgp/exabgp.in and exabgp.out were missing, they apparently need to exist as named pipes and be writable by nobody.

• Now, I use ExaBGP to set up two BGP sessions, one for IPv4 and one
  for IPv6, to announce members of a resolver cluster to our routers.

  The healthcheck module outputs (when run interactively)

announce route a.b.c.d/32 next-hop self med 100
announce route 2001:x:0:y:z::1/128 next-hop self med 101

This used to work nicely with ExaBGP 3.4, but apparently will not with ExaBGP 4.2.21. Running ExaBGP in the foreground with debug reveals

command from process recursor : announce route a.b.c.d/32 next-hop self med 100 
async | recursor | announce route a.b.c.d/32 next-hop self med 100
no neighbor matching the command : announce route a.b.c.d/32 next-hop self med 100

So... ExaBGP is now bone-headed enough to insist on an explicit neighbor specification
from the healthcheck script, even if there is only a single address-family-matching BGP session?
That makes it impossible to share the healthcheck config file between installations, because the neighbor
address (which is "of course" site-specific) creeps over from the ExaBGP config file itself into
the healthcheck configuration file, which is unfortunate.

• I see from the --help output of healthcheck that one can specify

  --neighbor NEIGHBOR   advertise the route to the selected neigbors

However, how NEIGHBOR goes from singular to plural (neighbors) is not explained.
What is the syntax for supplying multiple NEIGHBORs?

• And ... possibly the "neighbor" parameter can also be specified in the healthcheck configuration file?
  But ... one probably does not want an IPv4 route to be announced over an IPv6 BGP session, and I'm
  assuming there is no logic in healthcheck to match address families for route and neighborships?
  So this pushes me in the direction of having two separate healthcheck processes, one for IPv4 and
  one for IPv6? That ups the config complexity and the cost for the health checking, which is again unfortunate.

• Because I think the healthcheck script does not consume input
  (true? I've not been able to find a definitive answer to that...),
  I think I need to run with

[exabgp.api]
ack = false

That has the unfortunate side-effect that exabgpcli gets partially stuck
after executing a command, as has been noted already in #1164.

So, sorry, more of a rant to vent my frustration of the process, which is so far not finished.

I've already read https://github.com/Exa-Networks/exabgp/wiki/Migration-from-3.4-to-4.0

I also tried (and failed) to make sense of
https://github.com/Exa-Networks/exabgp/wiki/Configuration-:-Process

because this is, IMHO, to be charitable "light on explanation of actual semantics / behaviour modifications". I think I figured out that ExaBGP in 4.x needs "encoder text" added to the process section if using the "healthcheck" module, but that is by now more than a guess than anything else.

Answers or hints would be greatly appreciated.