The telnet client hung up in subprocess.Popen

[FAN Andy]

The telnet client dead in calling select function.

 

The telnet client is called by a expect script.

The expect script is called by subprocess.Popen

The subprocess.Popen is called by mod_wsgi

 

There is no problem if call the expect script directly.

There is no problem if call the subprocess.Popen from a python program.

When the subprocess.Popen is called from the mod_wsgi, the telnet client hung up in waiting the return of select

 

Is there some restriction for the sub process of mod_wsgi?

Why the select not work if it is the sub process of mod_wsgi?

 

 

The code detail is:

Code piece of python:

ScriptRun.BACKEND_PROCESS = subprocess.Popen(“/tmp/expect_shell.sh”, shell=True)

return ScriptRun.BACKEND_PROCESS   

 

Code piece of /tmp/expect_shell.sh:

spawn telnet $ipaddr;

    set timeout 10 ;

    expect \

    {

       timeout \

        {

            send_user "time out";

            exit 10;

        }

        default \      

        {

            send_user "ok";

            exit 10;

        }

   }

After execution of “spawn telnet $ipaddr;”, the telnet client did not output anything.

 

Code piece of telnet:

c = select(16, &ibits, &obits, &xbits,(poll == 0) ? NULL : &TimeValue);

Add trace in the telnet client source code, I find the program blocked in the select function when call from mod_wsgi

 

Thanks in advance.

 

 

 

 

 

 

 

[andy...@alcatel-lucent.com]

[Graham Dumpleton]

Sorry for delay. Moderation messages haven't been coming through. I am also away from home overseas and trying to reply to this through a phone, so be patient with me.

My first guess at problem is that the process being spawned is inheriting the signal mask from Apache or mod_wsgi daemon process which blocks signals at C level so only dealt with in a certain predictable way.

This can cause issues where sub processes rely on signals and has caused problems with certain spawned Java processes in the past which relied on signals to trigger garbage collection or something.

So if the expect code is relying on signals to wrap telnet that could be the problem. If this is the case you would need to create a back end service to do the real work, perhaps wrapped in Celery. That or use a simple XML-RPC service running under mini standalone web server.

See if that sounds reasonable.

Graham

> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>