Ah yes, read is not working because the TOOL subsystem is only able to use FS, KERBEROS, GSI, and CLAIMTOBE authentication, but I have been trying to work around those issues I have been having with Kerberos I mentioned last week. Has anyone been able to take another look at that? That error has me really stumped. Thanks for helping me find the root cause of that Todd, Wes Public Content -----Original Message----- From: Todd Tannenbaum <tannenba@xxxxxxxxxxx> Sent: Monday, August 3, 2020 9:47 AM To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>; Wesley Taylor <wesley.taylor@xxxxxxxxxxx> Subject: [External] - Re: [HTCondor-users] condor_q -better-analyze: "Could not fetch startd ads" CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 7/31/2020 6:20 PM, Wesley Taylor wrote: > Hey all, its me again. > > Finally got HTCondor ready for preliminary smoke testing on the production > network, and have been debugging issues as we go. There has been one really > weird error I haven't been able to figure out on my own. When I run > "condor_q" it runs fine. However, if I run "condor_q -analyze" or > "condor_q -better-analyze" I get back "Error: Could not fetch startd ads". On the same machine where "condor_q" works but "condor_q -analyze" fails, does "condor_status" work for you? If "condor_status" also does not work, then my guess is the security permissions on your pool's central manager are setup in a manner that is now allowing read access to the condor_collector from the machine where condor_status/condor_q -analyze fails. From this same machine try running this command to confirm/deny if read access is being blocked: condor_ping -pool condor.cs.wisc.edu -type collector READ If you can connect but READ is being denied, look at the ALLOW_READ setting in the condor_config file(s) on your central manager. Hope the above helps Todd
Attachment:
smime.p7s
Description: S/MIME cryptographic signature