Jenkins update; shell scripting question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Jenkins update; shell scripting question

Chris Cunnington
Hi All,

The Jenkins server is almost there. It produces xml files and presents
them with the Emma plugin. For the image, Lukas's code works almost
extant. I did have to comment out a class called Author, which we don't
have.

We get xml files. And Jenkins presents them with all the precision and
accuracy that Lukas created them with. So far so good. But there's a
wrinkle I need help with.

Starting the build is one thing. Stopping it - and stopping it at the
right time - is quite another. Left on its own, Jenkins will shut things
down after ~8 seconds. To do ~3000 tests in ~70 xml files takes ~90
seconds.

Lukas has two pieces of code that address this ... or, don't. I'm not
sure if both are necessary or if one of them is just for logging
purposes. My interest in logging is up there with tests, so I need to
get this right.

Naturally, there is one in the image and, another in the shell script.

For the image, you load in a script on startup of all the tests you want
to run. You add #snapshot:andQuit: at the end of that script.

But in the build.sh script there is this:

if [ $! ] ; then
     while kill -0 $! 2> /dev/null ; do

I think this is saying: "If there is a process running in the
background; while the last process running in the background cannot
receive a signal, do the following..."

So I have two questions:

1.) Why would a process not be able to receive a signal?
2.) And if it couldn't, then what would that tell me.

After I can figure out this last item, then I should be able to open up
the squeakci.org site next week.

Thanks,
Chris



# wait for the process to terminate, or a debug log
if [ $! ] ; then
     while kill -0 $! 2> /dev/null ; do
         if [ -f "$OUTPUT_DUMP" ] || [ -f "$OUTPUT_DEBUG" ] ; then
             sleep 5
             kill -s SIGKILL $! 2> /dev/null
             if [ -f "$OUTPUT_DUMP" ] ; then
                 echo "$(basename $0): VM aborted ($PHARO_VM)"
                 cat "$OUTPUT_DUMP" | tr '\r' '\n' | sed 's/^/  /'
             elif [ -f "$OUTPUT_DEBUG" ] ; then
                 echo "$(basename $0): Execution aborted ($PHARO_VM)"
                 cat "$OUTPUT_DEBUG" | tr '\r' '\n' | sed 's/^/  /'
             fi
             exit 1
         fi
         sleep 1
     done
else
     echo "$(basename $0): unable to start VM ($PHARO_VM)"
     exit 1
fi


Reply | Threaded
Open this post in threaded view
|

Re: Jenkins update; shell scripting question

Bert Freudenberg

On 26.04.2012, at 11:27, Chris Cunnington wrote:

> if [ $! ] ; then
>    while kill -0 $! 2> /dev/null ; do
>
> I think this is saying: "If there is a process running in the background; while the last process running in the background cannot receive a signal, do the following..."


I would read it as "while the VM is still alive (able to receive signals), do ..."

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Jenkins update; shell scripting question

Yanni Chiu
In reply to this post by Chris Cunnington
On 26/04/12 2:27 PM, Chris Cunnington wrote:
>
> ... Left on its own, Jenkins will shut things
> down after ~8 seconds. To do ~3000 tests in ~70 xml files takes ~90
> seconds.

I'm pretty sure that, left on its own, Jenkins will let the job run
until it exits by itself, and otherwise lets it run "forever".

The problem that the build.sh script is trying to address is to
terminate the squeak VM when it does NOT exit by itself. The script
terminates the squeak VM process, when it seems like it cannot handle
signals, or when a Debug.log file has appeared.

Before this build script change, the failing Hudson/Jenkins jobs would
never stop on their own. There was a plugin available for Hudson, which
would abort the job, if it exceeded a configurable time limit - which
was a poor solution.

> So I have two questions:
>
> 1.) Why would a process not be able to receive a signal?
> 2.) And if it couldn't, then what would that tell me.

1) There's probably lots of ways a process could stop handling signals.
2) If it couldn't, then it's a good guess that the build/test is stuck,
and should therefore be terminated.

Depending on which squeak VM you are using, you may have to change the
shell variable, $OUTPUT_DEBUG, to SqueakDebug.log instead of PharoDebug.log.