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 |