<br><br><div class="gmail_quote">On Tue, Mar 26, 2013 at 12:44 PM, Kevin Van Workum <span dir="ltr">&lt;<a href="mailto:vanw@sabalcore.com" target="_blank">vanw@sabalcore.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Mar 26, 2013 at 2:34 PM, John Valdes <span dir="ltr">&lt;<a href="mailto:valdes@anl.gov" target="_blank">valdes@anl.gov</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Glen Beane wrote:<br>
<div>&gt; David Beer wrote:<br>
&gt; &gt; Our QA tests have exposed that when a job file is loaded saying that it&#39;s<br>
</div>&gt; &gt; state is running but there is no exec host list defined [...]<br>
<div>&gt; &gt; I can think of two different behaviors:<br>
&gt; &gt;<br>
&gt; &gt; 1. delete the job<br>
&gt; &gt; 2. requeue the job<br>
&gt; &gt;<br>
&gt; &gt; Which one would you all prefer?<br>
&gt;<br>
</div><div>&gt; of course, the best solution is to find the bug that caused the<br>
&gt; corruption and keep the job file consistent.  In my opinion, it is<br>
&gt; hard to know what the &quot;right thing&quot; to do is in this case.  Is this<br>
&gt; something you see often?  Silently handling it (rerunning) may not be<br>
&gt; the right thing -- this should definitely be brought to someone&#39;s<br>
&gt; attention. But at the same time, &quot;disappearing jobs&quot; aren&#39;t good<br>
</div>&gt; either [...]<br>
<div>&gt;<br>
&gt; I guess I would lean towards rerunning if the job is &quot;rerunnable&quot;,<br>
&gt; emailing the user with some kind of error message if it is not,  and<br>
&gt; in all cases log the error.  But i&#39;m not 100% convinced.<br>
<br></div></blockquote></div></div></blockquote><div><br></div><div>Writing code to handle error cases isn&#39;t in lieu of trying to prevent them from happening. However, it is important to note that for many things, such as dealing with a filesystem or a network, it is virtually impossible to prevent them from happening in all cases, and if you don&#39;t write error handling code you are setting yourself up for failure.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
</div>My sentiments match Glen&#39;s.  How about a 3rd option:<br>
<br>
3. place a system hold on the job<br>
<br>
Then the admin can investigate to see why the job got into this state<br>
and determine the proper course of action.<br>
<br>
John<br></blockquote><div><br></div></div><div>I agree with option 3, system hold it, then requeue.</div></div>

<br></blockquote><div><br></div><div>Sounds like the consensus is to place a system hold on the job. </div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<img><br>_______________________________________________<br>
torqueusers mailing list<br>
<a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
<a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>David Beer | Senior Software Engineer</div><div>Adaptive Computing</div>