[Zope] shell command in zope on linux

[Andrew Langmead]

On Feb 12, 2005, at 4:09 AM, Bernd Dorn wrote:

> i have a testcase which runs the surrounding method successfully  
> (python only no zope), but wenn i access the method from zope it hangs  
> when the pdftk command tries to write to the output files and i have  
> to kill -9 the pdftk processes
>

This may be another case where Python's signal handling problems are  
screwing up the way the child process executes. The fully blocked  
signal mask in inherited by the process you spawn, and many programs do  
not expect to be starting up with all their signals blocked.

One way of proving this theory is to alter your test case to run in a  
thread rather than be executed by the main thread. Your requests to  
Zope will always be running in non-main threads, and so if your test is  
in a thread you will get a better apples to apples comparison.

The signal problem is definitely the reason why you have to "kill -9"  
rather than a simple "kill -INT"

If the test case stops working when run from a thread, you might want  
to try the following patch:

	<http://sourceforge.net/tracker/? 
func=detail&aid=1088832&group_id=5470&atid=305470>

Or at the very least, arrange some other way for pdftk to get access to  
its signals. The following C program is a rough sketch towards what you  
would need. If you compile it with a name like "unblock", you would run  
it like this:

	unblock pdftk /tmp/tmpRy0O_T.pdf fill_form /tmp/tmpz4mEG1.fdf output  
/tmp/tmpx1TxTD.pdf flatten


/* unblock.c
     unblock signals before running the specified process
*/
#include <stdio.h>
#include <signal.h>

int main(int argc, char **argv) {
     sigset_t blank;
     char *prog;
     int err;

     sigemptyset(&blank);
     sigprocmask(SIG_SETMASK, &blank, NULL);
     argv++;
     prog = *argv;
     err = execvp(prog, argv);
     if(err) {
         fprintf(stderr, "Error running %s: %d", prog, err);
     }
     return err;
}