SUBMIT_ATTRS is applied to the basic job ad before we parse the submit file, so anything in the submit file will override it. if you wanted to override what the user specified, you should probably do that in a JOB_TRANSFORM in the schedd. condor_submit is the only tool that has its own “daemon” (i.e. subsystem) name. It was added many years ago so that SUBMIT_ATTRS would work. The other tools are subsystem TOOL. -tj From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of Michael Pelletier Excellent! This is very elegant and straightforward. I think I see what’s going on here - I hadn’t realized that SUBMIT was another daemon type, and that you could use the conditional config in that way to pick out only the particular daemon you want. Nice. I was thinking of having my user_job_wrapper run a condor_qedit on its job, but this is much less failure-prone. Does this override what’s in the submit description, or get overridden by it? I also added: Notification = ifThenElse(( isUndefined(InteractiveJob) || InteractiveJob =!= true ) && ProcID + 1 == TotalSubmitProcs,"Always","Never") I.e., don’t notify at all on interactive jobs, and only notify on the last job in the cluster. -Michael Pelletier. From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of John M Knoeller I don’t think STARTD_JOB_ATTRS is what you want here, (and SYSTEM_STARTD_JOB_ATTRS is for use by HTCondor developers, not admins) Add this to the config of your submit machine, it will cause condor_submit to run the script and add the NotifyUser attribute to each job submitted. IsSubmit = false SUBMIT.IsSubmit = true if $(IsSubmit) include command : /usr/libexec/condor/get_notify_user $ENV{LOGNAME} if defined Notify_user SUBMIT_ATTRS = $(SUBMIT_ATTRS) NotifyUser NotifyUser = “$(Notify_user)” endif endif |