[Zope] shell command in zope on linux

[Bernd Dorn]

Andrew Langmead wrote:
> 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;
> }
> 

thanks for your detailed answer ...

it is exactly the problem you described and this is also the reason why 
it works on my mac machine where i've installed python 2.4, and the 
signal stuff is 2.3 specific

i did not try the python patch, but used your unclock.c, and now it 
works, great!!

thx a lot, bernd