Re: [HTCondor-users] ep custom configuration

[Antonio Falabella <antonio.falabella@xxxxxxx>]

Hi,

I update on this , the solution you proposed works for us. Just a couple 
of things to

whoever wants to implement this. We implemented signal capture mechanism 
on our jobs that let them end gracefully

when a custom signal is sent to them. So along with the custom class add 
creation we also kill the running jobs.

The second thing to consider is that custom classad wil not be available 
real time even if you reschedule it very fast (which is still fine for us).

Thanks

Antonio

On 25/04/25 14:40, Steffen Grunewald wrote:
> Hi Antonio,
>
> On Fri, 2025-04-25 at 13:55:55 +0200, HTCondor Users Mailinglist wrote:
> > Dear developers,
> >
> > I looking for a specific configuration of the execution points of a cluster
> > that I am configuring. The use case is the following: we have big cluster
> > for data acquisition that must allow the execution of jobs through condor
> > only when it is idle, that is when data acquisition is not running. When the
> > data acquisition starts the worker nodes must not run any new jobs. This
> > should be dynamic and looking in the documentation here:
> >
> > https://htcondor.readthedocs.io/en/latest/admin-manual/ep-policy-configuration.html
> >
> > in particular the "START Expression" this is something very similar to the
> > behavior that can be obtained with "KeyboardIdle" machine classad. Now the
> > question comes, is it possible to have a a custom machine classad like the
> > keyboard one that say, given the status of the machine it enables or
> > disables the job submission? The state of the machine exposed through the
> > machine classad should be custom i.e. if some particular process starts on
> > the machine or some other condition happens then I can set
> >
> > a START expression like
> >
> > START = NewCustomClassAd > 15 * $(MINUTE)
> >
> > To me it looks like I can mimic the structure of condor_kbdd and create a
> > custom daemon that exposes the before mentioned custom machine classad. But
> > I am here to ask you if there is something easier to accomplish this.
> At first glance, a STARTD_CRON job/hook (run periodically, detecting the running
> task and setting an attribute accordingly) might do what you're looking for?
> You may want to keep in mind that it'll take a while for the ClassAd to migrate
> and be used for matching _new_ jobs; also the START expression won't affect any
> jobs that are _already running_...
>
> Best,
>   Steffen