If it never sends an XML-RPC response back, you may want to close STDIN, STDOUT and maybe other open files after you fork. You can do it in /usr/local/bin/monster but it would be better to do it before you exec(). (You can also set close-on-exec if you know how to do that.)

Well, funnily enough the XML-RPC response occurs correctly. the applet doesn't specifically 'wait' for a response, but the XML-RPC class I'm using seems to want to wait anyway:

if(mx.getRun()){
                Vector params = new Vector();
                params.add(mx.toString());
                try{
                    client.execute("Monster.go", params);
                    getAppletContext().showDocument(new URL("http://mo
+nster.northwestern.edu/monster.jsp?pji="+id));
                 }
                catch(ConnectException ex){ex.printStackTrace();}
                catch(IOException ex){ex.printStackTrace();}
                catch(XmlRpcException ex){
                    ex.printStackTrace();
                    try{
                        getAppletContext().showDocument(new URL("http:
+//monster.northwestern.edu/monster.jsp?pji="+id));
                    }catch(MalformedURLException exc){exc.printStackTr
+ace();}
                }
            }
[download]

i added the '.showDocument' in the XmlRpcException catch, because it threw if it got a return that was weird, so just knowing that a return happened tells me the 'exec' happened (i hope). adding that catch didnt change a thing about the button hanging.

To answer your question:

Is the program "/usr/local/bin/monster" interacting with the XML-RPC client or does it just go off and do its own thing?

monster does its own thang, the 'return 0' in the daemon IS the final interaction with the XML-RPC client.

i'll have a go at checking where the hanging happens in the daemon, cheers

Sam