inexplicable command start delay

Whether this is specific to TW I’m not sure, but it seems to be both TW and Leap. I haven’t recorded yet which of many installations of Leap and TW have started doing this. I’ve been switching my TWs over from wicked to systemd-networkd, but whether I’ve observed any before & after connection I don’t recall as yet.

Apparently it’s not easy to test due to caching. Instant retries seem to have been producing instant response. I’ve been sensing DNS or hostname or hosts trouble, but as yet have not followed up on it until now. Just starting MC on a vtty, which should be instantaneous, has taken several seconds lately. I remember some bug many moons in the past that caused such slowness with MC startup which fix had something to do with networking. I’ve seen similar pausing in other procedures/apps involving networking as a part of startup, though ATM I can’t think of anything other than manually mounting an NFS export.

Virtually all of my installations are configured with static IPs, IPV6 disabled, and the very same hosts file with “127.0.0.1 localhost” but no 127.0.0.2, and 50 lines of local hosts, few of which are ever online at once. Via /etc/resolv.conf, some hosts use my router as primary nameserver, others 1.1.1.1 or 8.8.4.4. There is no wireless in use except for Rokus and Amazon Fire TV.

No virtualization here, except for OS/2 running DOS apps.

Has anyone noticed anything like this? What should I be looking at?

Too much tinkering? I disabled nscd. Enable debugging for the presumed culprits by adding:

**erlangen:~ #** cat /etc/systemd/system/systemd-udevd.service.d/override.conf 
[Service] 
#Environment=SYSTEMD_LOG_LEVEL=debug 
**erlangen:~ #**