<div dir="ltr">There have been two fixes for this issue: <div><br></div><div>1. Add more logging and checking to verify that the mother superior is rejecting the specified job. This fix went into 4.1.6/4.2.3 and resolved the problem for most users that reported it.</div>
<div>2. Have pbs_server remember when the mother superior has reported on the job and not abort for this reason if mother superior has reported the job to pbs_server in the last 180 seconds. This fix has been released with 4.2.4 and will be released with 4.1.7. Of the users I know of that were still experiencing this defect after 4.1.6 they are no longer experiencing it with this change in place.</div>
<div><br></div><div>David</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 6:33 AM, Kenneth Hoste <span dir="ltr">&lt;<a href="mailto:kenneth.hoste@ugent.be" target="_blank">kenneth.hoste@ugent.be</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Was this problem ever resolved?<br>
<br>
I noticed through <a href="http://www.clusterresources.com/pipermail/torqueusers/2012-December/015352.html" target="_blank">http://www.clusterresources.com/pipermail/torqueusers/2012-December/015352.html</a> that David looked into this, but the archive doesn&#39;t show any further followup.<br>

<br>
It seems we&#39;re currently suffering from a very similar problem with the Torque v4.1.6...<br>
<br>
<br>
regards,<br>
<br>
Kenneth<br>
<br>
PS: Please keep me in CC when replying, for some reason I&#39;m no longer receiving mails from torqueusers@ even though I&#39;m subscribed...<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 22 Nov 2012, at 16:46, Lech Nieroda wrote:<br>
<br>
&gt; Dear list,<br>
&gt;<br>
&gt; we have another serious problem since our upgrade to Torque 4.1.3. We<br>
&gt; are using it with Maui 3.3.1. The problem in a nutshell: some few,<br>
&gt; random jobs are suddenly &quot;unknown&quot; to the server, it changes their<br>
&gt; status to EXITING-SUBSTATE55 and requests a silent kill on the compute<br>
&gt; nodes. The job then dies, the processes are killed on the node, there is<br>
&gt; no &quot;Exit_status&quot; in the server-log, no entry in maui/stats, no<br>
&gt; stdout/stderr files. The users are, understandably, not amused.<br>
&gt;<br>
&gt; It doesn&#39;t seem to be user or application specific. Even a single<br>
&gt; instance from a job array can get blown away in this way while all other<br>
&gt; instances end normally.<br>
&gt;<br>
&gt; Here are some logs of such a job (681684[35]):<br>
&gt;<br>
&gt; maui just assumes a successful completion:<br>
&gt; [snip]<br>
&gt; 11/21 19:24:49 MPBSJobUpdate(681684[35],681684[35].cheops10,TaskList,0)<br>
&gt; 11/21 19:24:49 INFO: Average nodespeed for Job 681684[35] is  1.000000,<br>
&gt; 1.000000, 1<br>
&gt; 11/21 19:25:55 INFO:     active PBS job 681684[35] has been removed from<br>
&gt; the queue.  assuming successful completion<br>
&gt; 11/21 19:25:55 MJobProcessCompleted(681684[35])<br>
&gt; 11/21 19:25:55 INFO:     job &#39;681684[35]&#39; completed  X: 0.063356  T:<br>
&gt; 10903  PS: 10903  A: 0.063096<br>
&gt; 11/21 19:25:55 MJobSendFB(681684[35])<br>
&gt; 11/21 19:25:55 INFO:     job usage sent for job &#39;681684[35]&#39;<br>
&gt; 11/21 19:25:55 MJobRemove(681684[35])<br>
&gt; 11/21 19:25:55 MJobDestroy(681684[35])<br>
&gt; [snap]<br>
&gt;<br>
&gt; pbs_server decides at 19:25:11, after 3 hours runtime, that the job is<br>
&gt; unknown (grepped by JobID from the server logs):<br>
&gt; [snip]<br>
&gt; 11/21/2012<br>
&gt; 16:23:43;0008;PBS_Server.26038;Job;svr_setjobstate;svr_setjobstate:<br>
&gt; setting job 681684[35].cheops10 state from RUNNING-TRNOUTCM to<br>
&gt; RUNNING-RUNNING (4-42)<br>
&gt; 11/21/2012<br>
&gt; 19:25:11;0008;PBS_Server.26097;Job;svr_setjobstate;svr_setjobstate:<br>
&gt; setting job 681684[35].cheops10 state from RUNNING-RUNNING to<br>
&gt; QUEUED-SUBSTATE55 (1-55)<br>
&gt; 11/21/2012<br>
&gt; 19:25:11;0008;PBS_Server.26097;Job;svr_setjobstate;svr_setjobstate:<br>
&gt; setting job 681684[35].cheops10 state from QUEUED-SUBSTATE55 to<br>
&gt; EXITING-SUBSTATE55 (5-55)<br>
&gt; 11/21/2012<br>
&gt; 19:25:11;0100;PBS_Server.26097;Job;681684[35].cheops10;dequeuing from<br>
&gt; smp, state EXITING<br>
&gt; 11/21/2012<br>
&gt; 19:25:14;0001;PBS_Server.26122;Svr;PBS_Server;LOG_ERROR::kill_job_on_mom, stray<br>
&gt; job 681684[35].cheops10 found on cheops21316<br>
&gt; [snap]<br>
&gt;<br>
&gt; pbs_client just kills the processes:<br>
&gt; [snip]<br>
&gt; 11/21/2012 16:23:43;0001;   pbs_mom.32254;Job;TMomFinalizeJob3;job<br>
&gt; 681684[35].cheops10 started, pid = 17452<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: killing pid 17452 task<br>
&gt; 1 gracefully with sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: process<br>
&gt; (pid=17452/state=R) after sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: process<br>
&gt; (pid=17452/state=Z) after sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: killing pid 17692 task<br>
&gt; 1 gracefully with sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: process<br>
&gt; (pid=17692/state=R) after sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: killing pid 17703 task<br>
&gt; 1 gracefully with sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: process<br>
&gt; (pid=17703/state=R) after sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: killing pid 17731 task<br>
&gt; 1 gracefully with sig 15<br>
&gt; 11/21/2012 19:25:14;0008;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;kill_task: process<br>
&gt; (pid=17731/state=R) after sig 15<br>
&gt; 11/21/2012 19:25:15;0080;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;scan_for_terminated: job<br>
&gt; 681684[35].cheops10 task 1 terminated, sid=17452<br>
&gt; 11/21/2012 19:25:15;0008;   pbs_mom.32254;Job;681684[35].cheops10;job<br>
&gt; was terminated<br>
&gt; 11/21/2012 19:25:50;0001;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;preobit_reply, unknown on server,<br>
&gt; deleting locally<br>
&gt; 11/21/2012 19:25:50;0080;<br>
&gt; pbs_mom.32254;Job;681684[35].cheops10;removed job script<br>
&gt; [snap]<br>
&gt;<br>
&gt; Sometimes, the pbs_mom logs include this message before the killing starts:<br>
&gt; [snip]<br>
&gt; Req;req_reject;Reject reply code=15001(Unknown Job Id Error), aux=0,<br>
&gt; type=StatusJob, from PBS_Server@cheops10<br>
&gt; [snap]<br>
&gt;<br>
&gt; And finally, some job informations given to epilogue:<br>
&gt; [snip]<br>
&gt; Nov 21 19:25:15 s_sys@cheops21316 epilogue.shared:<br>
&gt; 681684[35].cheops10,hthiele0,cheops21316,Starting shared epilogue<br>
&gt; Nov 21 19:25:15 s_sys@cheops21316 epilogue.shared:<br>
&gt; 681684[35].cheops10,hthiele0,cheops21316,Job Information:<br>
&gt; userid=hthiele0,<br>
&gt; resourcelist=&#39;mem=5gb,ncpus=1,neednodes=1:ppn=1,nodes=1:ppn=1,walltime=48:00:00&#39;,<br>
&gt; resourcesused=&#39;cput=03:00:46,mem=945160kb,vmem=1368548kb,walltime=03:01:34&#39;,<br>
&gt; queue=smp, account=ccg-ngs, exitcode=271<br>
&gt; [snap]<br>
&gt;<br>
&gt; This happens rarely (about 1 in 3000). However, silent deletions of<br>
&gt; random jobs aren&#39;t exactly a trifling matter.<br>
&gt; I could try to disable the mom_job_sync option, which could perhaps<br>
&gt; prevent the process killing of unknown jobs, but it would also leave<br>
&gt; corrupt/pre-execution jobs alive.<br>
&gt;<br>
&gt; Can this be fixed?<br>
&gt;<br>
&gt; On a side-note, here are some further, minor Bugs I&#39;ve noticed in the<br>
&gt; Torque 4.1.3. Version:<br>
&gt; - the epilogue script is usually invoked twice and sometimes even<br>
&gt; several times<br>
&gt; - when explicit node lists are used, e.g. nodes=node1:ppn=2+node2:ppn=2,<br>
&gt; then the number of &quot;tasks&quot; as seen by qstat is zero<br>
&gt; - there have been some API changes between Torque 2.x and Torque 4.x, so<br>
&gt; that two maui calls had to be altered in order to build against Torque<br>
&gt; 4.x (get_svrport, openrm).<br>
&gt;<br>
&gt;<br>
&gt; Regards,<br>
&gt; Lech Nieroda<br>
&gt;<br>
&gt; --<br>
&gt; Dipl.-Wirt.-Inf. Lech Nieroda<br>
&gt; Regionales Rechenzentrum der Universität zu Köln (RRZK)<br>
&gt; Universität zu Köln<br>
&gt; Weyertal 121<br>
&gt; Raum 309 (3. Etage)<br>
&gt; D-50931 Köln<br>
&gt; Deutschland<br>
&gt;<br>
&gt; Tel.: +49 (221) 470-89606<br>
&gt; E-Mail: <a href="mailto:nieroda.lech@uni-koeln.de">nieroda.lech@uni-koeln.de</a><br>
&gt; _______________________________________________<br>
&gt; torqueusers mailing list<br>
&gt; <a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
&gt; <a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>David Beer | Senior Software Engineer</div><div>Adaptive Computing</div>
</div>