[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] is there some kind of caching for condor_q requests ?
- Date: Fri, 28 Feb 2020 11:28:59 -0600
- From: Todd Tannenbaum <tannenba@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] is there some kind of caching for condor_q requests ?
On 2/28/2020 11:09 AM, Jin Mao wrote:
Users are always right. :)
Maybe you can try to approach customers to introduce something like condor_wait to get job status from a user log file
instead of condor_q, if this is the reason to run condor_q more frequently than enough?
Hi Christoph and Jin,
Jin had the same ideas we had :)
We have developed a new tool called "condor_watch_q", which is similar to doing "watch condor_q", except is uses the job
event log (i.e. the file created when you do 'log=<some_file>' in your submit file) instead of hitting the schedd. This
tool should appear in the next 8.9 release. The tool is written in python on top of the HTCondor python bindings, so it
should be easy for you to customize if you need to, and/or make pull requests back to us if you have improvements.
Also, be aware of something similar that has existed in HTCondor for a long time (in HTCondor v8.6, v8.8, ...): the
condor_q tool already has a "-userlog <file>" command line option. From the man page on condor_q:
(general option) Display jobs, with job information coming from a job event log, instead of from the real ClassAds from the condor_schedd daemon. This is most useful for automated testing of the status of jobs known to be in the given job event log, because it reduces the load on the condor_schedd. A job event log does not contain all of the job information, so some fields in the normal output of condor_q will be blank.
Hope the above helps,