<div dir="ltr">Hi Mihael,<div><br></div><div>Moving the STDIN block from _swiftwrap to _swiftwrap.staging did not make any difference, ie. it did not work.</div><div><br></div><div>Changing</div><div><div><br></div><div>"$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR"</div><div><br></div><div>to</div><div><br></div><div>"$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR" </dev/null</div></div><div><br></div><div>in _swiftwrap.staging did work. I think it is a good idea to make this amend to the code.</div><div><br></div><div>Thanks,</div><div>Ketan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 3:43 PM, Ketan Maheshwari <span dir="ltr"><<a href="mailto:ketan@mcs.anl.gov" target="_blank">ketan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, I realized your question now. I have copied the whole if ... fi block (including genScripts) from _swiftwrap to _swiftwrap.staging to see what happens. Will keep you posted. --Ketan</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 3:37 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Right. However, you mentioned before that it works fine when you switch<br>
staging from "direct" to "swift". That causes swift to use the plain<br>
_swiftwrap, which pretty much has the same code:<br>
<br>
</span><span>if [ "$STDIN" == "" ]; then<br>
        if [ "$SWIFT_GEN_SCRIPTS" != "" ]; then<br>
</span><span>                genScripts<br>
        fi<br>
<br>
            if [ -n "$TIMECMD" ] && [ -n "$TIMEARGS" ]; then<br>
</span>               "$TIMECMD" "${TIMEARGS[@]}" "$EXEC" "${CMDARGS[@]}"<br>
<span>1>"$STDOUT" 2>"$STDERR"<br>
            else<br>
</span><span>               "$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR"<br>
</span><span>            fi<br>
else<br>
...<br>
<br>
So that's what's puzzling to me.<br>
<br>
Can you try changing this line in _swiftwrap.staging:<br>
<br>
</span><span>"$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR"<br>
<br>
</span><span>to<br>
<br>
"$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR" </dev/null<br>
<br>
and then remove stdin= from the app in the swift script and seeing if<br>
that works?<br>
<br>
While it seems like a wise choice to do this in general, I'm trying to<br>
see if this fixes this particular issue.<br>
<br>
</span>Mihael<br>
<br>
<span><br>
On Wed, 2015-03-04 at 15:22 -0600, Ketan Maheshwari wrote:<br>
</span><div><div>> Hi Mihael,<br>
><br>
> The code in _swiftwrap.staging branches based on if STDIN is present or<br>
> not. See the snippet below:<br>
><br>
> if [ "$STDIN" == "" ]; then<br>
>     if [ "$SWIFT_GEN_SCRIPTS" != "" ]; then<br>
>         echo "#!/bin/bash" > run.sh<br>
>         echo "\"$EXEC\" \"${CMDARGS[@]}\" 1>\"$STDOUT\" 2>\"$STDERR\"" >><br>
> run.sh<br>
>         chmod +x run.sh<br>
>     fi<br>
>     "$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR"<br>
> else<br>
>     if [ "$SWIFT_GEN_SCRIPTS" != "" ]; then<br>
>         echo "#!/bin/bash" > run.sh<br>
>         echo "\"$EXEC\" \"${CMDARGS[@]}\" 1>\"$STDOUT\" 2>\"$STDERR\"<br>
> <\"$STDIN\"" >> run.sh<br>
>         chmod +x run.sh<br>
>     fi<br>
>     "$EXEC" "${CMDARGS[@]}" 1>"$STDOUT" 2>"$STDERR" <"$STDIN"<br>
> fi<br>
><br>
> When "stdin=" is not provided the code takes the first branch and hangs. It<br>
> works otherwise.<br>
><br>
> It is possible that it hangs because if mpich bug Mike mentioned.<br>
><br>
> I agree we should stick in a </dev/null in there.<br>
><br>
> --Ketan<br>
><br>
><br>
> On Wed, Mar 4, 2015 at 3:12 PM, Hategan-Marandiuc, Philip M. <<br>
> <a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>> wrote:<br>
><br>
> > I'm still confused. I don't see any difference in stdin handling between<br>
> > _swiftwrap and _swiftwrap.staging (which is used for direct staging).<br>
> ><br>
> > Maybe we should always feed the app a /dev/null if there is no stdin=<br>
> > specified.<br>
> ><br>
> > Mihael<br>
> ><br>
> > On Wed, 2015-03-04 at 08:50 -0600, Ketan Maheshwari wrote:<br>
> > > I added stdin="/dev/null" to app invocation line and it has worked now.<br>
> > > --Ketan<br>
> > ><br>
> > > On Wed, Mar 4, 2015 at 8:44 AM, Ketan Maheshwari <<a href="mailto:ketan@mcs.anl.gov" target="_blank">ketan@mcs.anl.gov</a>><br>
> > wrote:<br>
> > ><br>
> > > > Please find one with 59 minutes attached. --Ketan<br>
> > > ><br>
> > > > On Tue, Mar 3, 2015 at 11:17 PM, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>><br>
> > > > wrote:<br>
> > > ><br>
> > > >> You are using coasters, so what gets queued is the block, not the job.<br>
> > > >><br>
> > > >> You should specify execution.options.maxJobTime = "00:59:00".<br>
> > > >><br>
> > > >> Then you can probably do a walltime of about "00:50:00". But 7 minutes<br>
> > > >> vs. 5 minutes isn't much of a difference.<br>
> > > >><br>
> > > >> Mihael<br>
> > > >><br>
> > > >> On Tue, 2015-03-03 at 22:28 -0600, Ketan Maheshwari wrote:<br>
> > > >> > Attached is a log for maxWalltime set to 7 minutes beyond which the<br>
> > job<br>
> > > >> > does not get submitted because of the 1 hour walltime limit of<br>
> > Cetus.<br>
> > > >> > --Ketan<br>
> > > >> ><br>
> > > >> > On Tue, Mar 3, 2015 at 10:15 PM, Ketan Maheshwari <<br>
> > <a href="mailto:ketan@mcs.anl.gov" target="_blank">ketan@mcs.anl.gov</a>><br>
> > > >> wrote:<br>
> > > >> ><br>
> > > >> > > When I check queue with qstat, I see the job is submitted for 40<br>
> > > >> minutes.<br>
> > > >> > > When I try to increase maxWallTime the workflow does not get<br>
> > submitted<br>
> > > >> > > because on Cetus maximum allowed walltime is 60 minutes. --Ketan<br>
> > > >> > ><br>
> > > >> > > On Tue, Mar 3, 2015 at 10:03 PM, Hategan-Marandiuc, Philip M. <<br>
> > > >> > > <a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>> wrote:<br>
> > > >> > ><br>
> > > >> > >> Hi,<br>
> > > >> > >><br>
> > > >> > >> Looks like almost exactly 5 minutes to me:<br>
> > > >> > >><br>
> > > >> > >> 2015-03-04 01:45:43,943+0000 INFO  Execute TASK_STATUS_CHANGE<br>
> > > >> > >> taskid=urn:R-3-0-2-1425432781969 status=2<br>
> > > >> > >> workerid=0304-3301040-000000:000000<br>
> > > >> > >> 2015-03-04 01:50:44,676+0000 INFO  Execute TASK_STATUS_CHANGE<br>
> > > >> > >> taskid=urn:R-3-0-2-1425432781969 status=5 Walltime exceeded<br>
> > > >> > >><br>
> > > >> > >> Which is what the config file is asking for:<br>
> > > >> > >><br>
> > > >> > >> app.bgsh {<br>
> > > >> > >>   env.SUBBLOCK_SIZE: "16"                                 # [R]<br>
> > line<br>
> > > >> 27<br>
> > > >> > >>   executable: "/home/ketan/SwiftApps/subjobs/bg.sh"       # [R]<br>
> > line<br>
> > > >> 25<br>
> > > >> > >>   maxWallTime: "00:05:00"                                 # [R]<br>
> > line<br>
> > > >> 26<br>
> > > >> > >> }<br>
> > > >> > >><br>
> > > >> > >> Again, the wrapper log shows the app as still running. Last line<br>
> > is:<br>
> > > >> > >> Progress  2015-03-04 01:45:43.971393118+0000  EXECUTE<br>
> > > >> > >><br>
> > > >> > >> Please do me a favor and increase the walltime to one hour and<br>
> > let's<br>
> > > >> see<br>
> > > >> > >> what happens then.<br>
> > > >> > >><br>
> > > >> > >> If it still doesn't finish after one hour, we could try to<br>
> > strace it<br>
> > > >> and<br>
> > > >> > >> see what is happening there.<br>
> > > >> > >><br>
> > > >> > >> Mihael<br>
> > > >> > >><br>
> > > >> > >> On Tue, 2015-03-03 at 19:53 -0600, Ketan Maheshwari wrote:<br>
> > > >> > >> > Please find the log attached. --Ketan<br>
> > > >> > >> ><br>
> > > >> > >> > On Tue, Mar 3, 2015 at 7:03 PM, Hategan-Marandiuc, Philip M. <<br>
> > > >> > >> > <a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>> wrote:<br>
> > > >> > >> ><br>
> > > >> > >> > > On Tue, 2015-03-03 at 15:42 -0600, Ketan Maheshwari wrote:<br>
> > > >> > >> > > > Slow network looks unlikely to be a cause:<br>
> > > >> > >> > ><br>
> > > >> > >> > > It's the only variable obvious, so I wouldn't say that.<br>
> > > >> > >><br>
> > > >> > >> I meant "only obvious variable" there.<br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > ><br>
> > > >><br>
> > > >><br>
> > > >> _______________________________________________<br>
> > > >> Swift-devel mailing list<br>
> > > >> <a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
> > > >> <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
> > > >><br>
> > > ><br>
> > > ><br>
> ><br>
> ><br>
> ><br>
<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>