Making clients continuously trying to resolve and connect server

[eMPee584]

In case of network resolution errors or a server booted after the clients, these should never stop retrying to find and connect to the epoptes-server instance.
[With mdns enabled it was difficult to get it to work and from monitoring the client service it seems to stop its efforts to hook up to the server under some conditions]

[alkisg]

The loop you describe already exists:
https://github.com/epoptes/epoptes/blob/main/epoptes-client/epoptes-client#L126

Epoptes-client only aborts when the DNS appears to work and yet the SERVER name doesn't resolve to a normal IP.
For example, with the default SERVER=server entry, we don't want a client process to keep trying to connect to server when that entry isn't declared at all in /etc/hosts.

I think the problem that you describe only affects MDNS; I'll look into it some time in the future, and possibly special-case the ".local" domain.

[eMPee584]

Epoptes-client only aborts when the DNS appears to work and yet the SERVER name doesn't resolve to a normal IP.

which is the case when the server computer has not yet started. It would be great if that could be disabled by an option at least..

[alkisg]

DNS works even when the target computers are powered off.
E.g. host www.google.com will tell you the google IP even if google is down at the moment.

I believe only MDNS has the problem you describe (when you're using computer.local this isn't DNS, it's MDNS), I'll test it when I get some free time, thanks.

[eMPee584]

Yes MDNS of course. The clients are set up with

SERVER=epoptes-server.local
connection.mdns=2

the server runs avahi-daemon with

use-ipv4=yes
use-ipv6=no
enable-wide-area=no
publish-aaaa-on-ipv4=no

# 1 = Try to detect unicast dns servers that serve .local and disable avahi in that case,
# 0 = Don't try to detect .local unicast dns servers, can cause
# troubles on misconfigured networks
AVAHI_DAEMON_DETECT_LOCAL=1

Gonna try with a modified epoptes-client script and report back (closed inadvertently)

[alkisg]

@eMPee584 does this patch work for you?

8bf9c53

[eMPee584]

[…]
Yes, thank you, it seems to work 😃
Here's a small follow-up patch to make the control flow clearer: f4928dc

[alkisg]

@eMPee584 thanks but I think your patch will cause 100% CPU usage because it avoids the sleep call.

[eMPee584]

Yes you're right of course, though the getent call takes enough time to not let the CPU run hot..
Here's a quick fix.. 3ab8b0f
Maybe waiting only 5 seconds is a bit overambitious but at least it makes all clients show up rapidly once the server comes up 😁

[alkisg]

I too was thinking that the 60 seconds delay is a bit too long, but that's another issue, to be handled separately, not as part of this one.