Thank you David!  This has been a known issue for a while and I haven't had time
to look into it.  This particular patch might not be completely appropriate
because it may block for up to one second if the select timeout is reached.  I
think it may be necessary to change *when* the old "drain" is called to avoid
this instead of doing another select.

David Creemer wrote:
> whoops -- I messed up the formatting of my patch -- here's another try..
> 
> -- David
> 
> 
> 
> On Sun, 29 Mar 2009 00:10 -0700, "David Creemer"
> <[email protected]> wrote:
>> In April, 2008 there was a brief thread on this list with the same
>> subject as this message (see
>> http://lists.supervisord.org/pipermail/supervisor-users/2008-April/000216.html)
>>
>> The basic problem is that stopping a process through supervisorctl
>> sometimes fails to log the last bit of output from a process. This is
>> especially the case if you put something like a print of "shutting down"
>> in the SIGTERM handler of your sub-process. This is exactly what I did,
>> and so I had this same issue. I traced the problem to the deceptively
>> simple "drain()" method in process.py. Drain is called just before the
>> process is killed, but if there is no output pending from the
>> subprocess, the call to read data is misinterpreted as an EOF, and the
>> pipes are closed. It seems that the a dispatcher should only be read
>> from if there is actual data waiting.
>>
>> Enclosed is a rough patch (against top of trunk) to make drain work like
>> the main select() loop (in fact the code is liberally lifted from the
>> main select loop...). It seems to work for me.
>>
>> Thanks,
>> -- David
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Supervisor-users mailing list
>> [email protected]
>> http://lists.supervisord.org/mailman/listinfo/supervisor-users

_______________________________________________
Supervisor-users mailing list
[email protected]
http://lists.supervisord.org/mailman/listinfo/supervisor-users

Reply via email to