On Wed 22 Feb 2023 at 17:45:40 (+0100), Christoph Brinkhaus wrote: > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: > > On 22/02/2023 01:26, Christoph Brinkhaus wrote: > > > > > I have no idea if it is possible to estimate a DHCP response > > > > > time. > > > > Since static IP address is assigned, it does not matter. I expected DHCP > > configuration and that delay may be noticed in `journalctl -b 0` logs. > > > > > [Unit] > > > Description=A remote mail retrieval and forwarding utility > > > After=network-online.target opensmtpd.service unbound.service > > > Requires=opensmtpd.service unbound.service > > > > > > But fetchmail starts before the dependencies have been finished. > > > > I can not say that I fully understand interaction of After and > > Requires/Wants options. I would try additional Wants=network-online.target > > As far as I remeber correctly I have tried the Wants option without > success. > > In case of my fetchmail setup the culprit is unbound. At the startup > of unbound it takes some time to exchange keys and so on. During that > period names cannot be resolved. Now I call fetchmail after the > mailserver name can be resolved to an IP. This is done in a tiny > wrapper script. It keeps the log files clean. That workaround is fine > for me. > > > > [Match] > > > Name=w* > > > > > > [Network] > > > DHCP=no > > > Address=192.168.0.62/24 > > > Gateway=192.168.0.32 > > > DNS=127.0.0.1 > > > > There are options like RequiredForOnline, see systemd.network(5), but likely > > default value is yes.
Might you try systemd-networkd-wait-online.service, whose name implies that it waits for up to two minutes (configurable default). > > However avahi-autoipd should be started concurrently > > with network configuration to assign link-local address in the case of > > failure. > In a different thread - it was about IPv6 which has mutated > slightly - several users claimed that the avahi-autoip is useful for > their business. I am only a hobbyist, I trust the guys who do IT in > their regular job. May be it is ok as it is implemented in Debian. I agree with that. I think the people that report problems on the list are, with possible exceptions, trying to get their networks into better shape. Perhaps one problem is that getting a 169.254.x.y address might be useful if you're expecting to join an ad hoc network, but if you're not (like, I suspect, many of us here), it only complicates matters. For the latter, better surely to get no address, notice the fact, and fix the networking, rather than to have to do all that /and/ get rid of the 169.254.x.y address. Cheers, David.
