[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] condor_rm problems

Hi Greg,

Thanks for your answer! Why is it necessary to talk to the negotiator
for deleting jobs from the queue? Can't I just turn this behavior off?

Is there any other situation (querying the queue, like condor_q
-global, or submitting new jobs) when it can be a problem too if I
turn off the negotiator (problem = slows down things and eats up
memory as I understand)?

Actually, I turn off the negotiator to disable negotiation for a
while. Could you suggest another simple (and fast) way to turn off
negotiation temporarily other than shutting down the negotiator
completely? START=False for example not a viable solution, because as
far as I know I have to change the value on every machine, and
regarding the fact that machines are coming and going all the time,
there's no guarantee that a "hiding" machine won't just pop up after
the reconfiguration, and negotiator starts to negotiate again...

Thanks again,

2014-01-31 Greg Thain <gthain@xxxxxxxxxxx>:
> On 01/31/2014 04:23 AM, Pek Daniel wrote:
>> And after the restart of condor_schedd, it continued "working on" the
>> deletion of jobs, and it has been working for more than 1 hour now and
>> it uses up more and more memory (I don't know for what reason...)
> At the moment, it is spending a lot of time trying to talk to the
> negotiator.  I think if you turned it back on, the rm's would go a lot
> faster.
> -greg
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/