<div>I&#39;m waiting to see if the community can find a hole in my logic.  I&#39;ll have to admit that I&#39;m relatively new to pbs and I realize there are a lot of things done for historical (or platform compatibility reasons) I don&#39;t appreciate. </div>

<div> </div>
<div>One issue I see.. what happens if the user&#39; shell accepts:</div>
<blockquote style="MARGIN-RIGHT:0px" dir="ltr">
<div><font face="courier new,monospace">/path/to/some/job/script.SC</font></div></blockquote>
<div>which Torque does today, but not</div>
<blockquote style="MARGIN-RIGHT:0px" dir="ltr">
<div><font face="courier new,monospace">exec /path/tp/some/job/script.SC</font></div></blockquote>
<div>.. which is what I&#39;m proposing.  I checked the shells that I have on hand (sh, ksh, bash, csh, tcsh, zsh) and all of these appear fine, but I&#39;m only checking on RHEL Linux and I fully appreciate that other OS&#39;s sh and csh implementations can be quite different (but I would be quite surprised if they can&#39;t exec).  While this covers the 95% case, there could be some esoteric shell out there that proves incompatible.</div>

<div> </div>
<div>That said, I find myself wondering why Torque uses the users&#39;s shell doesn&#39;t just use /bin/sh (which is pretty much going to exist on any Unix machine out there).  I&#39;m guessing that there could be some subtle things in the user&#39;s environment that make the job script work under their shell that could fail if invoked under /bin/sh (assuming they aren&#39;t an sh-user)... but at least Torque would be gauranteed of the shell&#39;s behavior (and it would gaurantee that the above &quot;exec&quot; issue couldn&#39;t happen).  Personally, I&#39;m tempted to suggest that Torque should have a --always-use-sh compile time option :)</div>

<div> </div>
<div>Of course, the environment problem I&#39;m describing should be quite familiar to anyone that uses cron and people have worked around that for years (decades?) so I would think some sites could live with that option.</div>

<div> </div>
<div>Again, I&#39;m relatively new and there may be some subtle interaction between pbs_mom, job_scripts and pbs_demux I&#39;m not picking up on, but in the testing I&#39;ve been able to do thus far... it works fine for me.  </div>

<div> </div>
<div>-Alan<br><br></div>
<div class="gmail_quote">On Tue, Mar 13, 2012 at 11:24 AM, <span dir="ltr">&lt;<a href="mailto:torquedev-request@supercluster.org">torquedev-request@supercluster.org</a>&gt;</span> wrote:</div>
<div class="gmail_quote">----------------------------------------------------------------------<br><br>Message: 1<br>Date: Tue, 13 Mar 2012 10:04:41 -0600<br>From: David Beer &lt;<a href="mailto:dbeer@adaptivecomputing.com">dbeer@adaptivecomputing.com</a>&gt;<br>
Subject: Re: [torquedev] &quot;Fixing&quot; qsig -s USR1 and kill_delay on<br>       torque 2.5.x<br>To: Torque Developers mailing list &lt;<a href="mailto:torquedev@supercluster.org">torquedev@supercluster.org</a>&gt;<br>
Message-ID:<br>       &lt;<a href="mailto:CAFUQeZ1bpV-uzgm-qgQvAZnDZVY5J3bPvHSnkPOh-La4_hP%2B3g@mail.gmail.com">CAFUQeZ1bpV-uzgm-qgQvAZnDZVY5J3bPvHSnkPOh-La4_hP+3g@mail.gmail.com</a>&gt;<br>Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<br>
<br>Having done the work it takes to configure these signals to work in the<br>system&#39;s current state, I&#39;m all for addressing this issue. I&#39;m wondering if<br>there are any community concerns about this change? Do you see any possible<br>
regressions? What are the risks? Should we make this change something that<br>only happens if you turn it on in the mom config file? In some ways I like<br>this option because it is easy to turn off if there are regressions, but on<br>
the other hand the kill_delay functionality is so cumbersome to set up its<br>essentially broken now. I&#39;m interested to hear the community&#39;s input on<br>this patch.<br><br>David<br><br>On Tue, Mar 13, 2012 at 8:53 AM, Alan Wild &lt;<a href="mailto:alan@madllama.net">alan@madllama.net</a>&gt; wrote:<br>
<br>&gt; (wipes egg off face)... if it isn&#39;t obvious.. I haven&#39;t had to do any<br>&gt; heavy C-coding in a few months.<br>&gt;<br>&gt; I wrote the loop in the previous pass knowing fully that strcpy() doesn&#39;t<br>
&gt; support overlapping memory regions.  All of a sudden last night... I<br>&gt; recalled memmove() did.  Here&#39;s an updated patch against the latest 2.5.11<br>&gt; snapshot using memmove() and no loop.<br>&gt;<br>&gt; Yes.. and I also realize I screwed up the diff.  That&#39;s what I get trying<br>
&gt; to hand-tune it to not have it bounded by whatspace.  This one should apply<br>&gt; cleanly with  patch -p1<br>&gt;<br>&gt; -Alan<br>&gt;<br>&gt; diff -rN -U2 torque-2.5.11-snap.201203081434-old/src/resmom/start_exec.c<br>
&gt; torque-2.5.11-snap.201203081434/src/resmom/start_exec.c<br>&gt; --- torque-2.5.11-snap.201203081434-old/src/resmom/start_exec.c 2012-03-08<br>&gt; 15:34:57.000000000 -0600<br>&gt; +++ torque-2.5.11-snap.201203081434/src/resmom/start_exec.c     2012-03-13<br>
&gt; 09:47:55.000000000 -0500<br>&gt; @@ -1997,4 +1997,9 @@<br>&gt;      int k;<br>&gt;  +    if (strlen(buf)+5 &lt;= MAXPATHLEN) {<br>&gt; +        memmove(buf+5,buf,strlen(buf)+1);<br>&gt; +        strncpy(buf, &quot;exec &quot;, 5);<br>
&gt; +    }<br>&gt; +<br>&gt;      /* pass name of shell script on pipe */<br>&gt;      /* will be stdin of shell  */<br>&gt; On Mon, Mar 12, 2012 at 3:38 PM, Alan Wild &lt;<a href="mailto:alan@madllama.net">alan@madllama.net</a>&gt; wrote:<br>
&gt;<br>&gt;<br>&gt;&gt; NOTE:  we are presently running 2.5.7, but I&#39;ve confirmed that this <br>&gt;&gt; change is still applicable to 2.5.9.  I&#39;ve not had a chance to look at 3.x<br>&gt;&gt; or 4.x in any way.<br>
&gt;&gt;<br>&gt;&gt; We recently wanted to change our kill_delay on our system to allow jobs<br>&gt;&gt; adequate time to properly clean up in the event of a qdel.  At the same<br>&gt;&gt; time I started playing with qsig and discovered that sending a USR1 signal<br>
&gt;&gt; to process would cause it to terminate (even if the jobscript/job properly<br>&gt;&gt; handled SIGUSR1).<br>&gt;&gt;<br>&gt;&gt; It tuns out that both issues are related to the same problem: The failure<br>&gt;&gt; of the user&#39;s shell (by default) to catch and properly handle signals.<br>
&gt;&gt; This has been discussed here (and on torqueusers) several times in the past<br>&gt;&gt; and the general recommendation has always been to have the user add the<br>&gt;&gt; necessary &quot;trap&quot; statements to their .bashrc (or appropriate file) in<br>
&gt;&gt; addition to putting them in their job script.<br>&gt;&gt;<br>&gt;&gt; The reasons for these recommendations stems from the process hierarchy<br>&gt;&gt; that is created by pbs_mom:<br>&gt;&gt;<br>&gt;&gt; pbs_mom,6488 -p<br>
&gt;&gt;   `-bash,10919<br>&gt;&gt;      `-16398.hpdjsl001,10978 -l /var/spool/pbs/mom_priv/jobs/<br>&gt;&gt; <a href="http://16398.hpdjsl001.sc/" target="_blank">16398.hpdjsl001.SC</a> &lt;<a href="http://16398.hpdjsl001.sc/" target="_blank">http://16398.hpdjsl001.sc/</a>&gt;<br>
&gt;&gt;<br>&gt;&gt; pbs_mom launches a shell (in my case bash) which, in turn, invokes the<br>&gt;&gt; job script.  When the user executes a qsig or qdel... the server passes the<br>&gt;&gt; signal to the mom and the mom signals both of these processes.  If the job<br>
&gt;&gt; script has the necessary trap calls in it... it, of course, handles the<br>&gt;&gt; signal properly, but the shell process will exit... and many shells will<br>&gt;&gt; exit even on on a seemingly innocuous SIGUSR1.<br>
&gt;&gt;<br>&gt;&gt; If the shell process exits... the pbs_mom believes the job to have died<br>&gt;&gt; and automatically enters into a mode where it sends a SIGTERM to the<br>&gt;&gt; jobscript and ~5seconds later a SIGKILL.  This happens whether regardless<br>
&gt;&gt; of the singal the user sent (even SIGUSR1) or in the event of a qdel.<br>&gt;&gt; However, given that the goal of a qdel is to remove a job... most Torque<br>&gt;&gt; users are probably none the wiser that it isn&#39;t going through the &quot;correct&quot;<br>
&gt;&gt; termination sequence.<br>&gt;&gt;<br>&gt;&gt; We have a large user community (and most are not technical enough) that I<br>&gt;&gt; don&#39;t reasonably expect them to be able to properly implement the changes<br>
&gt;&gt; to their individual login files.  I&#39;ve considering having our system<br>&gt;&gt; configuration files updated, but this would affect all users (even those<br>&gt;&gt; that don&#39;t submit jobs) and I we would be stuck maintaining a solution that<br>
&gt;&gt; works for each of about five different shells we have installed.<br>&gt;&gt;<br>&gt;&gt; So I wondered if there couldn&#39;t be a better way.<br>&gt;&gt;<br>&gt;&gt; I looked at the pbs_mom source and found how the pbs_mom passes the<br>
&gt;&gt; script command to invoked into the shell process.  It does so via a pipe<br>&gt;&gt; which is connected to the shell&#39;s stdin. So I thought, &quot;why couldn&#39;t the<br>&gt;&gt; shell simply &#39;exec&#39; the job script instead of running it as a simple<br>
&gt;&gt; command line?&quot;  It turns out that the pipe is closed shortly after the<br>&gt;&gt; script&#39;s path is passed to the shell so it&#39;s not like pbs_mom was going to<br>&gt;&gt; talk to the shell anymore... so why leave the shell running?  If the shell<br>
&gt;&gt; is no longer running... that&#39;s one less process to have worry about<br>&gt;&gt; catching signals... and potentially it&#39;s less memory wasted on the compute<br>&gt;&gt; node.<br>&gt;&gt;<br>&gt;&gt; I threw together this rather small patch as a prototype:<br>
&gt;&gt;<br>&gt;&gt; diff -urN torque-2.5.7/src/resmom/start_exec.c<br>&gt;&gt; torque-2.5.7-new/src/resmom/start_exec.c<br>&gt;&gt; --- torque-2.5.7/src/resmom/start_exec.c        2011-06-17<br>&gt;&gt; 17:15:57.000000000 -0500<br>
&gt;&gt; +++ torque-2.5.7-new/src/resmom/start_exec.c    2012-03-12<br>&gt;&gt; 13:29:13.000000000 -0500<br>&gt;&gt; @@ -1966,5 +1966,11 @@<br>&gt;&gt;                 {<br>&gt;&gt;                 int k;<br>&gt;&gt;<br>&gt;&gt; +               if (strlen(buf)+5 &lt;= MAXPATHLEN) {<br>
&gt;&gt; +                       for (i=strlen(buf); i&gt;=0; i--)<br>&gt;&gt; +                               buf[i+5] = buf[i];<br>&gt;&gt; +                       strncpy(buf, &quot;exec &quot;, 5);<br>&gt;&gt; +               }<br>
&gt;&gt; +<br>&gt;&gt;                 /* pass name of shell script on pipe */<br>&gt;&gt;                 /* will be stdin of shell  */<br>&gt;&gt;<br>&gt;&gt; ...And found it to work as expected in our test environment (with<br>
&gt;&gt; admittedly limited testing).  All this does, (if there is still space in<br>&gt;&gt; the buffer) is shifts everything over 5 characters and inserts &quot;exec &quot; at<br>&gt;&gt; the beginning of the command line. The shell invokes the process, which of<br>
&gt;&gt; course, now exec&#39;s the script. The script inherits the pid of the shell as<br>&gt;&gt; well as its stdin/stdout/stderr so pbs_demux appears to function correctly.<br>&gt;&gt;<br>&gt;&gt; Every shell I&#39;ve investigated (sh, csh, ksh, bash, zsh) all appear to<br>
&gt;&gt; honor the &quot;exec&quot; command in the same manner so this appears to be a viable<br>&gt;&gt; solution to this problem (premature shell termination) without requiring<br>&gt;&gt; users (or admins) to add &quot;trap&quot; statements to dotfiles to protect that one<br>
&gt;&gt; process.  For the record, this doesn&#39;t get anyone off the hook about<br>&gt;&gt; installing trap&#39;s in the job scripts (or signal handlers in the processes<br>&gt;&gt; themselves), but this appears to remove one of larger barriers in<br>
&gt;&gt; leveraging qsig(1) and extended kill_delay settings.<br>&gt;&gt;<br>&gt;&gt; I&#39;lll concede there could be a flaw in my logic, and as I stated above,<br>&gt;&gt; this has only had limited testing thus far, but I would love to hear what I<br>
&gt;&gt; may have missed and why this couldn&#39;t be a viable change in Torque.<br>&gt;&gt;<br>&gt;&gt; This was tested by qsub&#39;ing the following perl script directly (no shell<br>&gt;&gt; job-script around it).  This code simply catches signals, prints the time<br>
&gt;&gt; that they were received, and after the first signal is caught... prints the<br>&gt;&gt; time in 1 second intervals (since you&#39;ll never see the final SIGKILL you<br>&gt;&gt; can at least count of the seconds).<br>
&gt;&gt;<br>&gt;&gt; #!/usr/bin/perl -l<br>&gt;&gt; use constant CATCH =&gt; qw/USR1 USR2 HUP TERM INT QUIT ABRT ILL FPE SEGV<br>&gt;&gt; ALRM PIPE CHLD/;<br>&gt;&gt; my $stop;<br>&gt;&gt; $|=1;<br>&gt;&gt;<br>&gt;&gt;  @SIG{(CATCH)} = (sub { $stop||=1; print join &#39; &#39;, shift, &#39;@&#39;, scalar<br>
&gt; localtime }) x CATCH;<br>&gt;  sleep unless $stop;<br>&gt; print (scalar localtime), sleep 1 while 1;<br>&gt; When tested with a qdel, you&#39;ll see a TERM signal logged at the time<br>&gt; invocation, followed by the number of printouts which correspond with your<br>
&gt; kill_delay setting (defaults to 2 seconds).  Finally you see a second<br>&gt; SIGTERM and then ~5 seconds later the output stops (because the process<br>&gt; receives a SIGKILL).  For the unfamiliar, when the server asks a mom to do<br>
&gt; a SIGKILL... it is hard coded to SIGTERM first and then ~5 seconds later to<br>&gt; try a SIGKILL.<br>&gt;<br>&gt; Without my patch above (and without adding trap statements to your<br>&gt; .bashrc) this script will output two SIGTERM&#39;s (typically within the same<br>
&gt; second) with about 5 more seconds of printouts (before the final kill).<br>&gt; mom_logs will confirm that the initial SIGTERM terminated the shell<br>&gt; process, and that the mom then automatically initiated a job termination<br>
&gt; (via the second TERM and KILL).<br>&gt;<br>&gt; I also won&#39;t take any offense if someone wants to implement the patch more<br>&gt; efficiently, I was just trying to do what I wanted with the minimal amount<br>&gt; of change to the torque code.<br>
&gt;<br>&gt; Thanks,<br>&gt;<br>&gt; -Alan<br>&gt;<br>&gt; --<br>&gt; <a href="mailto:alan@madllama.net">alan@madllama.net</a> <a href="http://humbleville.blogspot.com/" target="_blank">http://humbleville.blogspot.com</a><br>
&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; --<br>&gt; <a href="mailto:alan@madllama.net">alan@madllama.net</a> <a href="http://humbleville.blogspot.com/" target="_blank">http://humbleville.blogspot.com</a><br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>
&gt; torquedev mailing list<br>&gt; <a href="mailto:torquedev@supercluster.org">torquedev@supercluster.org</a><br>&gt; <a href="http://www.supercluster.org/mailman/listinfo/torquedev" target="_blank">http://www.supercluster.org/mailman/listinfo/torquedev</a><br>
&gt;<br>&gt;<br><br><br>--<br>David Beer | Software Engineer<br>Adaptive Computing<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://www.supercluster.org/pipermail/torquedev/attachments/20120313/68bdfe0f/attachment-0001.html" target="_blank">http://www.supercluster.org/pipermail/torquedev/attachments/20120313/68bdfe0f/attachment-0001.html</a><br>
<br>------------------------------<br><br>Message: 2<br>Date: Tue, 13 Mar 2012 10:07:36 -0600 (MDT)<br>From: <a href="mailto:bugzilla-daemon@supercluster.org">bugzilla-daemon@supercluster.org</a><br>Subject: [torquedev] [Bug 168] 2.5(.9) qsub does not seem to accept<br>
       comma seperated -W argument<br>To: <a href="mailto:torquedev@supercluster.org">torquedev@supercluster.org</a><br>Message-ID: &lt;<a href="mailto:20120313160736.7E6264121046@http.supercluster.org">20120313160736.7E6264121046@http.supercluster.org</a>&gt;<br>
Content-Type: text/plain; charset=&quot;UTF-8&quot;<br><br><a href="http://www.clusterresources.com/bugzilla/show_bug.cgi?id=168" target="_blank">http://www.clusterresources.com/bugzilla/show_bug.cgi?id=168</a><br><br>Ken Nielson &lt;<a href="mailto:knielson@adaptivecomputing.com">knielson@adaptivecomputing.com</a>&gt; changed:<br>
<br>          What    |Removed                     |Added<br>----------------------------------------------------------------------------<br>            Status|NEW                         |RESOLVED<br>        Resolution|                            |FIXED<br>
<br>--- Comment #6 from Ken Nielson &lt;<a href="mailto:knielson@adaptivecomputing.com">knielson@adaptivecomputing.com</a>&gt; 2012-03-13 10:07:36 MDT ---<br>Fixed in 2.5.11 revision 5803<br><br>--<br>Configure bugmail: <a href="http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email" target="_blank">http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email</a><br>
------- You are receiving this mail because: -------<br>You are on the CC list for the bug.<br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 13 Mar 2012 10:24:26 -0600<br>From: Ken Nielson &lt;<a href="mailto:knielson@adaptivecomputing.com">knielson@adaptivecomputing.com</a>&gt;<br>
Subject: Re: [torquedev] &quot;Fixing&quot; qsig -s USR1 and kill_delay on<br>       torque 2.5.x<br>To: Torque Developers mailing list &lt;<a href="mailto:torquedev@supercluster.org">torquedev@supercluster.org</a>&gt;<br>
Message-ID:<br>       &lt;CADvLK3dhjWYNqjYgficcs9EEuey+KW7h=<a href="mailto:9HBvgq9axg9tDx8FA@mail.gmail.com">9HBvgq9axg9tDx8FA@mail.gmail.com</a>&gt;<br>Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<br><br>Alan,<br>
<br>I&#39;m sorry I did not get to this sooner. I would like add this and test it.<br>We are up against a deadline to get torque 2.5.11 out. I would like to put<br>this in for 2.5.12 and get some testing for it. We can do a 2.5.12 release<br>
when we feel confident in this fix.<br><br>Regards<br><br>Ken<br><br>On Mon, Mar 12, 2012 at 2:38 PM, Alan Wild &lt;<a href="mailto:alan@madllama.net">alan@madllama.net</a>&gt; wrote:<br><br>&gt; NOTE:  we are presently running 2.5.7, but I&#39;ve confirmed that this change<br>
&gt; is still applicable to 2.5.9.  I&#39;ve not had a chance to look at 3.x or 4.x<br>&gt; in any way.<br>&gt;<br>&gt; We recently wanted to change our kill_delay on our system to allow jobs<br>&gt; adequate time to properly clean up in the event of a qdel.  At the same<br>
&gt; time I started playing with qsig and discovered that sending a USR1 signal<br>&gt; to process would cause it to terminate (even if the jobscript/job properly<br>&gt; handled SIGUSR1).<br>&gt;<br>&gt; It tuns out that both issues are related to the same problem: The failure<br>
&gt; of the user&#39;s shell (by default) to catch and properly handle signals.<br>&gt; This has been discussed here (and on torqueusers) several times in the past<br>&gt; and the general recommendation has always been to have the user add the<br>
&gt; necessary &quot;trap&quot; statements to their .bashrc (or appropriate file) in<br>&gt; addition to putting them in their job script.<br>&gt;<br>&gt; The reasons for these recommendations stems from the process hierarchy<br>
&gt; that is created by pbs_mom:<br>&gt;<br>&gt; pbs_mom,6488 -p<br>&gt;   `-bash,10919<br>&gt;      `-16398.hpdjsl001,10978 -l /var/spool/pbs/mom_priv/jobs/<br>&gt; <a href="http://16398.hpdjsl001.sc/" target="_blank">16398.hpdjsl001.SC</a><br>
&gt;<br>&gt; pbs_mom launches a shell (in my case bash) which, in turn, invokes the job<br>&gt; script.  When the user executes a qsig or qdel... the server passes the<br>&gt; signal to the mom and the mom signals both of these processes.  If the job<br>
&gt; script has the necessary trap calls in it... it, of course, handles the<br>&gt; signal properly, but the shell process will exit... and many shells will<br>&gt; exit even on on a seemingly innocuous SIGUSR1.<br>&gt;<br>
&gt; If the shell process exits... the pbs_mom believes the job to have died<br>&gt; and automatically enters into a mode where it sends a SIGTERM to the<br>&gt; jobscript and ~5seconds later a SIGKILL.  This happens whether regardless<br>
&gt; of the singal the user sent (even SIGUSR1) or in the event of a qdel.<br>&gt; However, given that the goal of a qdel is to remove a job... most Torque<br>&gt; users are probably none the wiser that it isn&#39;t going through the &quot;correct&quot;<br>
&gt; termination sequence.<br>&gt;<br>&gt; We have a large user community (and most are not technical enough) that I<br>&gt; don&#39;t reasonably expect them to be able to properly implement the changes<br>&gt; to their individual login files.  I&#39;ve considering having our system<br>
&gt; configuration files updated, but this would affect all users (even those<br>&gt; that don&#39;t submit jobs) and I we would be stuck maintaining a solution that<br>&gt; works for each of about five different shells we have installed.<br>
&gt;<br>&gt; So I wondered if there couldn&#39;t be a better way.<br>&gt;<br>&gt; I looked at the pbs_mom source and found how the pbs_mom passes the script<br>&gt; command to invoked into the shell process.  It does so via a pipe which is<br>
&gt; connected to the shell&#39;s stdin. So I thought, &quot;why couldn&#39;t the shell<br>&gt; simply &#39;exec&#39; the job script instead of running it as a simple command<br>&gt; line?&quot;  It turns out that the pipe is closed shortly after the script&#39;s<br>
&gt; path is passed to the shell so it&#39;s not like pbs_mom was going to talk to<br>&gt; the shell anymore... so why leave the shell running?  If the shell is no<br>&gt; longer running... that&#39;s one less process to have worry about catching<br>
&gt; signals... and potentially it&#39;s less memory wasted on the compute node.<br>&gt;<br>&gt; I threw together this rather small patch as a prototype:<br>&gt;<br>&gt; diff -urN torque-2.5.7/src/resmom/start_exec.c<br>&gt; torque-2.5.7-new/src/resmom/start_exec.c<br>
&gt; --- torque-2.5.7/src/resmom/start_exec.c        2011-06-17<br>&gt; 17:15:57.000000000 -0500<br>&gt; +++ torque-2.5.7-new/src/resmom/start_exec.c    2012-03-12<br>&gt; 13:29:13.000000000 -0500<br>&gt; @@ -1966,5 +1966,11 @@<br>
&gt;                 {<br>&gt;                 int k;<br>&gt;<br>&gt; +               if (strlen(buf)+5 &lt;= MAXPATHLEN) {<br>&gt; +                       for (i=strlen(buf); i&gt;=0; i--)<br>&gt; +                               buf[i+5] = buf[i];<br>
&gt; +                       strncpy(buf, &quot;exec &quot;, 5);<br>&gt; +               }<br>&gt; +<br>&gt;                 /* pass name of shell script on pipe */<br>&gt;                 /* will be stdin of shell  */<br>
&gt;<br>&gt; ...And found it to work as expected in our test environment (with<br>&gt; admittedly limited testing).  All this does, (if there is still space in<br>&gt; the buffer) is shifts everything over 5 characters and inserts &quot;exec &quot; at<br>
&gt; the beginning of the command line. The shell invokes the process, which of<br>&gt; course, now exec&#39;s the script. The script inherits the pid of the shell as<br>&gt; well as its stdin/stdout/stderr so pbs_demux appears to function correctly.<br>
&gt;<br>&gt; Every shell I&#39;ve investigated (sh, csh, ksh, bash, zsh) all appear to<br>&gt; honor the &quot;exec&quot; command in the same manner so this appears to be a viable<br>&gt; solution to this problem (premature shell termination) without requiring<br>
&gt; users (or admins) to add &quot;trap&quot; statements to dotfiles to protect that one<br>&gt; process.  For the record, this doesn&#39;t get anyone off the hook about<br>&gt; installing trap&#39;s in the job scripts (or signal handlers in the processes<br>
&gt; themselves), but this appears to remove one of larger barriers in<br>&gt; leveraging qsig(1) and extended kill_delay settings.<br>&gt;<br>&gt; I&#39;lll concede there could be a flaw in my logic, and as I stated above,<br>
&gt; this has only had limited testing thus far, but I would love to hear what I<br>&gt; may have missed and why this couldn&#39;t be a viable change in Torque.<br>&gt;<br>&gt; This was tested by qsub&#39;ing the following perl script directly (no shell<br>
&gt; job-script around it).  This code simply catches signals, prints the time<br>&gt; that they were received, and after the first signal is caught... prints the<br>&gt; time in 1 second intervals (since you&#39;ll never see the final SIGKILL you<br>
&gt; can at least count of the seconds).<br>&gt;<br>&gt; #!/usr/bin/perl -l<br>&gt; use constant CATCH =&gt; qw/USR1 USR2 HUP TERM INT QUIT ABRT ILL FPE SEGV<br>&gt; ALRM PIPE CHLD/;<br>&gt; my $stop;<br>&gt; $|=1;<br>&gt;<br>
&gt; @SIG{(CATCH)} = (sub { $stop||=1; print join &#39; &#39;, shift, &#39;@&#39;, scalar<br>&gt; localtime }) x CATCH;<br>&gt;<br>&gt; sleep unless $stop;<br>&gt; print (scalar localtime), sleep 1 while 1;<br>&gt;<br>&gt; When tested with a qdel, you&#39;ll see a TERM signal logged at the time<br>
&gt; invocation, followed by the number of printouts which correspond with your<br>&gt; kill_delay setting (defaults to 2 seconds).  Finally you see a second<br>&gt; SIGTERM and then ~5 seconds later the output stops (because the process<br>
&gt; receives a SIGKILL).  For the unfamiliar, when the server asks a mom to do<br>&gt; a SIGKILL... it is hard coded to SIGTERM first and then ~5 seconds later to<br>&gt; try a SIGKILL.<br>&gt;<br>&gt; Without my patch above (and without adding trap statements to your<br>
&gt; .bashrc) this script will output two SIGTERM&#39;s (typically within the same<br>&gt; second) with about 5 more seconds of printouts (before the final kill).<br>&gt; mom_logs will confirm that the initial SIGTERM terminated the shell<br>
&gt; process, and that the mom then automatically initiated a job termination<br>&gt; (via the second TERM and KILL).<br>&gt;<br>&gt; I also won&#39;t take any offense if someone wants to implement the patch more<br>&gt; efficiently, I was just trying to do what I wanted with the minimal amount<br>
&gt; of change to the torque code.<br>&gt;<br>&gt; Thanks,<br>&gt;<br>&gt; -Alan<br>&gt;<br>&gt; --<br>&gt; <a href="mailto:alan@madllama.net">alan@madllama.net</a> <a href="http://humbleville.blogspot.com/" target="_blank">http://humbleville.blogspot.com</a><br>
&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; torquedev mailing list<br>&gt; <a href="mailto:torquedev@supercluster.org">torquedev@supercluster.org</a><br>&gt; <a href="http://www.supercluster.org/mailman/listinfo/torquedev" target="_blank">http://www.supercluster.org/mailman/listinfo/torquedev</a><br>
&gt;<br>&gt;<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://www.supercluster.org/pipermail/torquedev/attachments/20120313/22ab13b4/attachment.html" target="_blank">http://www.supercluster.org/pipermail/torquedev/attachments/20120313/22ab13b4/attachment.html</a><br>
<br>------------------------------<br><br>_______________________________________________<br>torquedev mailing list<br><a href="mailto:torquedev@supercluster.org">torquedev@supercluster.org</a><br><a href="http://www.supercluster.org/mailman/listinfo/torquedev" target="_blank">http://www.supercluster.org/mailman/listinfo/torquedev</a><br>
<br><br>End of torquedev Digest, Vol 76, Issue 5<br>****************************************<br></div><br><br clear="all"><br>-- <br><a href="mailto:alan@madllama.net">alan@madllama.net</a> <a href="http://humbleville.blogspot.com">http://humbleville.blogspot.com</a><br>