[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Change JobUniverse from vanilla to local?
- Date: Thu, 21 Sep 2017 18:44:08 +0000
- From: John M Knoeller <johnkn@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Change JobUniverse from vanilla to local?
If it problem is that the submit node is the only machine with sufficient memory to run this job, one possible solution is to run a STARTD on the submit node that only accepts jobs with a certain attribute.
While you can't count on changing the job universe of a job using condor_qedit. you can certainly count on being able to add or modify some other attribute.
for instance. have the STARTD running on the submit node that has
START = TARGET.SpecialHighMemoryJob
And use condor_qedit to set
SpecialHighMemoryJob = true
In the situations where you were thinking of using condor_qedit to change JobUniverse to local.
From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx] On Behalf Of Steffen Grunewald
Sent: Thursday, September 21, 2017 2:31 AM
To: MIRON LIVNY <miron@xxxxxxxxxxx>
Cc: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] Change JobUniverse from vanilla to local?
On Wed, 2017-09-20 at 18:08:59 -0500, Miron Livny <miron@xxxxxxxxxxx> wrote:
> Just to double check, you want to change the JobUniverse after the Job was
> submitted by DAGMqn. I Assume you are aware that you can easily (via a pre
> or post script) this attribute after the DAGMan job was submitted but before
> the specific job was handed over by DAGMan to the SchedD.
it's already too late: when you find that a submitted job won't match any
available machine this after ... before timespan is over.
Thanks for the suggestion even if doesn't help now.
Changing the JobUniverse was only one possible (or rather impossible) option
to cope with oversized jobs generated by DagMan - fortunately there are more.
We're going for more memory in selected nodes.
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
You can also unsubscribe by visiting
The archives can be found at: