<div dir="ltr"><br>Sorry, what I wrote was confusing due to an errant paste.  Edited below.<div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 10, 2018 at 5:03 PM Daniel Povey <<a href="mailto:dpovey@gmail.com">dpovey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">I was able to fix it, although I suspect that my fix may have been disruptive to the jobs.<div><br></div><div>Firstly, I  believe the problem was that gridengine does not handle a deleted job (state 'dr') that is on a host that has been deleted, and it dies when it sees it.   Presumably the bug is in allowing it to be deleted in the first place.</div><div><br></div><div>Anyway, my fix (after backing up the directory /var/spool/gridengine) was to move the file /var/spool/gridengine/spooldb/sge_job to a temporary location, restart the qmaster, add the host back with qconf -ah, stop the qmaster, restore the old database  /var/spool/gridengine/spooldb/sge_job, and restart the qmaster.</div><div><br></div><div>Before doing that whole procedure, to stop the hosts getting confused I stopped all the gridengine-exec services.  That probably wasn't optimal because clients like qsub and qstat would still have been able to access the queue in the interim, and it definitely would have confused them and killed some processes.  Unfortunately I had to do this on short notice and wasn't sure how to use iptables to close off those ports from outside the qmaster while I did the maintenance-- that would have been a better solution. </div><div><br></div><div>Also I encountered a hiccup that `systemctl stop gridengine-qmaster` didn't actually work the second time, the process was still running, with the old database, so I had to manually kill it and retry.</div><div><br></div><div>Anyway this whole episode is making me think more seriously about moving to Univa GridEngine.  I've known for a long time that the free version has a lot of bugs, and I just don't have time to deal with this type of thing.</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 10, 2018 at 4:49 PM Marshall2, John (SSC/SPC) <<a href="mailto:john.marshall2@canada.ca" target="_blank">john.marshall2@canada.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div>Hi,</div>
<div><br>
</div>
<div>I've never seen this but I would start with:</div>
<div>1) strace qmaster during restart to try to see at which point it is dying (e.g.,</div>
<div>loading a config file)</div>
<div>2) look for any reference to the name of the host you deleted in the spool</div>
<div>area and do some cleanup</div>
<div>
<div>3) clean out the jobs spool area</div>
<div><br>
</div>
</div>
<div>HTH,</div>
<div>John</div>
<div><br>
</div>
<div>On Sat, 2018-11-10 at 16:23 -0500, Daniel Povey wrote:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">Has anyone found this error, and managed to fix it?
<div>I am in a very difficult situation.</div>
<div>I deleted a host (qconf -de hostname) thinking that the machine no longer existed, but it did exist, and there was a job in 'dr' state there.</div>
<div>After I attempted to force-delete that job (qdel -f job-id), the queue master died with out-of-memory, and now I can't restart qmaster.</div>
<div><br>
</div>
<div>So now I don't know hw to fix it.  Am I just completely lost now?</div>
<div><br>
</div>
<div>Dan</div>
</div>
<pre>_______________________________________________</pre>
<pre>users mailing list</pre>
<pre><a href="mailto:users@gridengine.org" target="_blank">users@gridengine.org</a></pre>
<pre><a href="https://gridengine.org/mailman/listinfo/users" target="_blank">https://gridengine.org/mailman/listinfo/users</a></pre>
<pre><br></pre>
</blockquote>
</div>

</blockquote></div>
</blockquote></div></div></div>