We’ve noticed for many years what seem to be harmless client syslog messages indicating that a request has triggered a change in proxy configuration, normally between ‘none’, a hostname, or ‘DIRECT’. Lately these messages have become more verbose, including a “manager” (‘external’ or ‘standard’) and various “reason” entries (“random start proxy from the first proxy group”, “cloned”). But the reason these are triggered is still a bit of a mystery. Our client proxy config is simple: one proxy “group” comprised of two entries of the DNS round robin alias for our two caches, which presumes the client will look up the alias twice and resolve both IP addresses, followed by ‘DIRECT’ as a fail-over.
Guessing at this behavior, since the primary default config file does not contain a proxy setting, even though our default local override file does, it seems the config may first read the configuration of the default config repository (cvmfs-config.cern.ch), which contains a line that may end up setting the proxy to ‘DIRECT’:
CVMFS_HTTP_PROXY=“${CVMFS_HTTP_PROXY:=DIRECT}”
Perhaps afterward the client then reads our default local override file, which does contain our local proxy config, and resets the variable?
A Github discussion from one year ago [1] seems to imply this client logging output is inaccurate, the cited “manager” is actually the cache manager and not a proxy manager, and to disable this behavior (and possibly this output?), the fallback proxy setting should be explicitly set empty. Is this still the case, and still the best way to address this? I don’t think there is nor ever was a proxy issue on our clients, and the extent of verbosity of these messages has caught the attention of our WN admins, who would prefer they were eliminated if they’re not useful.
[1] Proxy changed without reason to DIRECT · Issue #3648 · cvmfs/cvmfs · GitHub