Ryan, Since no one else has replied, I will try to explain what I think is happening although I have no idea why or how it is happening. I will also ask a few questions.
> On Aug 17, 2025, at 7:15 AM, Ryan C. Underwood <[email protected]> > wrote: > I recently tried out the 1.8.13.2 client on my Ubuntu laptop, > upgrading from a somewhat older client version. What is the version of Ubuntu and most importantly, what is the kernel version? > Historically, I have > used @sys-based components in PATH as a way of centrally managing > CLI tools without having to distribute them to every system I use. > However, this has become problematic in the following way. I’m not sure that @sys is involved. > > Immediately after system startup, all is well, my shell profile loads > immediately and CLI commands also return immediately. However, after > some time of system utilization, not necessarily including any heavy > AFS usage, doing anything within my shell profile slows to a crawl. > The reason is because of the AFS-based PATH component. Instead of > stat() calls returning immediately, at this point each one creates > many DNS roundtrips fetching some very strange SRV records that I do > not recall seeing before, and which are perhaps malformed: > > 12:52:12.101148 IP 192.168.8.248.46167 > 192.168.8.1.53: 25095+ AFSDB? > icequake.net/users/nemesis/bin/bash. (53) > 12:52:12.245481 IP 192.168.8.1.53 > 192.168.8.248.46167: 25095 NXDomain 0/1/0 > (128) > 12:52:12.246822 IP 192.168.8.248.57487 > 192.168.8.1.53: 46166+ AFSDB? > icequake.net/users/nemesis/bin/bash.icequake.net. (66) > 12:52:12.407925 IP 192.168.8.1.53 > 192.168.8.248.57487: 46166 NXDomain* > 0/1/0 (134) > 12:52:12.408765 IP 192.168.8.248.60842 > 192.168.8.1.53: 45806+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash. (73) > 12:52:12.612530 IP 192.168.8.1.53 > 192.168.8.248.60842: 45806 NXDomain 0/1/0 > (148) > 12:52:12.613264 IP 192.168.8.248.33038 > 192.168.8.1.53: 54461+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash.icequake.net. (86) > 12:52:12.817311 IP 192.168.8.1.53 > 192.168.8.248.33038: 54461 NXDomain* > 0/1/0 (154) > 12:52:12.817829 IP 192.168.8.248.33177 > 192.168.8.1.53: 53983+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash. (73) > 12:52:12.958650 IP 192.168.8.1.53 > 192.168.8.248.33177: 53983 NXDomain 0/1/0 > (148) > 12:52:12.959152 IP 192.168.8.248.50256 > 192.168.8.1.53: 12967+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/bin/bash.icequake.net. (86) > 12:52:13.124390 IP 192.168.8.1.53 > 192.168.8.248.50256: 12967 NXDomain* > 0/1/0 (154) > 12:52:13.125189 IP 192.168.8.248.47935 > 192.168.8.1.53: 56862+ AFSDB? > icequake.net/users/nemesis/bin/bash. (53) > 12:52:13.329797 IP 192.168.8.1.53 > 192.168.8.248.47935: 56862 NXDomain 0/1/0 > (128) > 12:52:13.330370 IP 192.168.8.248.58386 > 192.168.8.1.53: 55085+ AFSDB? > icequake.net/users/nemesis/bin/bash.icequake.net. (66) > 12:52:13.537502 IP 192.168.8.1.53 > 192.168.8.248.58386: 55085 NXDomain* > 0/1/0 (134) > 12:52:13.540776 IP 192.168.8.248.41895 > 192.168.8.1.53: 6729+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash. (78) > 12:52:13.740662 IP 192.168.8.1.53 > 192.168.8.248.41895: 6729 NXDomain 0/1/0 > (153) > 12:52:13.741143 IP 192.168.8.248.37102 > 192.168.8.1.53: 33110+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash.icequake.net. > (91) > 12:52:14.159513 IP 192.168.8.1.53 > 192.168.8.248.37102: 33110 NXDomain* > 0/1/0 (159) > 12:52:14.160055 IP 192.168.8.248.58652 > 192.168.8.1.53: 64126+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash. (78) > 12:52:14.731726 IP 192.168.8.1.53 > 192.168.8.248.58652: 64126 NXDomain 0/1/0 > (153) > 12:52:14.732197 IP 192.168.8.248.41774 > 192.168.8.1.53: 19149+ SRV? > _afs3-vlserver._udp.icequake.net/users/nemesis/@sys/bin/bash.icequake.net. > (91) > [...] There are two types of DNS queries being issued. The first type are DNS SRV queries for service “afs3-vlserver” using protocol “udp”. The second type of query are the deprecated DNS AFSDB queries the DNS SRV queries are intended to replace. However, the queries are malformed and are leaking to the world every path that is traversed. > Can someone explain what is going on here? Whatever is happening, it > is bypassing the cache manager because the same strange queries are > issued repeatedly as the shell profile executes. It's additionally > painful in the case of my laptop, since the ultimate DNS server is on > the other end of a VPN link. Unless the afsd dynamic root functionality is disabled, DNS SRV or DNS AFSDB queries would be expected if the cache manager’s CellServDB does not contain a list of database servers for the cell “ice quake.net”. In particular we would expect to see a DNS SRV query for :_afs3-vlserver._udp.icequake.net and if that query failed, then a fallback query for DNS AFSDB “icequake.net”. Those queries are not present in the above trace. As far as I can tell there are neither DNS SRV nor DNS AFSDB records published for ice quake.net. What is odd about the above queries is that they contain the full path with the exclusion of the “/afs/“ prefix. This is odd because it appears that the /afs/some-cell-name/path query is being treated as a single path component. For example: icequake.net/users/nemesis/bin/bash icequake.net/users/nemesis/bin/bash.icequake.net icequake.net/users/nemesis/@sys/bin/bash icequake.net/users/nemesis/@sys/bin/bash.icequake.net The full path is usually not visible to a filesystem. One question to answer is whether these paths are being delivered to the afs lookup function or whether they are being constructed internally? Filesystems do not normally have visibility to full paths so I wouldn’t expect them to be constructed internally. If the paths are being passed to the afs lookup function, then the failure to separate the components for lookup is somewhere higher in the stack. > I believe the previous version I was using (without this new behavior) > was 1.8.10, but don't quote me on that. What else changed between when 1.8.10 was installed and 1.8.13.2? I am curious if you experience the same behavior problems with the AuriStorFS client. If you do, that is a strong indication that the problem is external to OpenAFS. Jeffrey Altman _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
