Re: [HTCondor-users] Sending new Kerberos tickets for a running job?

[Jaime Frey <jfrey@xxxxxxxxxxx>]

> On Feb 3, 2026, at 5:44âAM, CMV <ciprian.vizitiu@xxxxxxxxxxxxxxx> wrote:
> 
> 
> On 2/3/26 12:17 AM, Jaime Frey via HTCondor-users wrote:
>> If the user runs kinit and then submits a new job, the Access Point will have a copy of the new cache. The Access Point will send the new cache to the Execution Points at the start of all new execution attempts.
> 
> I thought of that too and tested it by submitting the most simplistic "exit 0" type of shell job (after a kinit). Then the question quickly became how would I make it so that the new job is sent to the same AP? The only option for condor_submit that worked for me was ' -spool cm_node' and that makes it choose one or the other of the APs.
> 
> A better question would be: what is the process by which the AP discovers that condor_submit added a new Kerberos cache for a given user? For example if I manage to securely send the new cache to the AP and put it in say... SEC_CREDENTIAL_DIRECTORY or some other magic location (using the format username.cc), will it be picket up and sent tot EXEcs or do I have to send it explicitly via some API call(s) the same way condor_submit does?

condor_submit always submits to the same AP, either the âlocalâ one (found via files in the local HTCondor spool directory or the SCHEDD_HOST configuration parameter) or the one identified by the -name or -remote command-line option. Doing the latter (submitting to a remote AP) for jobs using credentials is tricky, since it involves talking to the condor_credd daemon that runs next to the condor_schedd, which condor_submit may not know how to contact. We know we need to improve that.

You should be able to use the condor_store_cred tool to update the kerberos credentials held by the AP.

 - Jaime