[pgpool-general: 2933] Re: Connections stuck in CLOSE_WAIT, again

[Tatsuo Ishii]

Can you please post stack trace with symbols?  I need identify the
code path. There are too may similar code path like this.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

> I have the same problem with PuppetDB fortend.
> When I stop the service of PuppetDB, all connections from pgpool is
> CLOSE_WAIT and in DISCARD state, even with connection timeout set to 1
> minute.
> here is the summery from gdb:
> 
> the hanged function is:
> __select_no_cancel() from /lib64/libc.so.6.
> 
> stacktrace output:
> 
> 0 __select_no_cancel() from /lib64/libc.so.6.
> 1 pool_check_fd
> 2 pool_read
> 3 read_kind_from_backend
> 4 ProcessBackendResponse
> 5 pool_process_query
> 6 fork_a_child()
> 7 reaper
> 8 pool_sleep
> 9 main
> 
> 
> 
> On Thu, Jun 19, 2014 at 2:29 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:
> 
>> You said your developer found pgpool child process in DISCARD state.
>>
>> Please attach gdb to the process in DISCARD state and take
>> backtrace. Also I need actual netsta -anp outputs.
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese:http://www.sraoss.co.jp
>>
>> >     Hi Tatsuo,
>> >
>> >     We are facing this same problem, and as I see it remains unsolved (or
>> >     perhaps they didn't report the solution).
>> >     We are using pgpool 3.3.3, with two postgres 9.1 in streaming
>> >     replication. The OS is Debian 3.2.54-2 (64bits).
>> >
>> >     The log shows messages like this:
>> >
>> >         ProcessFrontendResponse: failed to read kind from frontend.
>> frontend
>> >         abnormally exited
>> >
>> >     I'm not sure but it looks like one for each connection left unclosed.
>> >
>> >     Also, a ps -ef returns a lot of pgpool children in DISCARD state. And
>> >     the netstat -anp, gives the correspondent TCP connection in
>> CLOSE_WAIT
>> >     state.
>> >
>> >     The developer has checked the client process is closing the
>> >     connections and we try connecting directly to the postgres and it
>> >     worked fine.
>> >
>> >     When you say "to attach debugger", do you mean change log_statment =
>> >     true or debug_level to a value other than 0 or any other procedure?
>> >
>> >     Many thanks,
>> >
>> > --
>> > Juanjo Pérez
>> >
>> > www.oteara.com
>> >
>> > El 02/04/14 01:05, Tatsuo Ishii escribió:
>> >>> We have a client on 3.3 experiencing the the problem noted here:
>> >>>
>> >>>
>> http://www.sraoss.jp/pipermail/pgpool-general/2012-December/001283.html
>> >>>
>> >>> strace is showing the child processes at:
>> >>>
>> >>>     clone(child_stack=0,
>> >>>     flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>> >>>     child_tidptr=0x7fcf659f3a10) = 6258
>> >>>
>> >>> I didn't see any resolution of that issue; is there data we can gather
>> >>> to assist?
>> >> I followed the old 2012 posting with:
>> >>
>> >>> That means pgpool does not close the socket connected to by your
>> >>> applications. Is it possible to attach debugger to such that pgpool
>> >>> process to see what pgpool is doing?
>> >> But I got no response until now. Can you please do this?
>> >>
>> >> Best regards,
>> >> --
>> >> Tatsuo Ishii
>> >> SRA OSS, Inc. Japan
>> >> English: http://www.sraoss.co.jp/index_en.php
>> >> Japanese: http://www.sraoss.co.jp
>> >> _______________________________________________
>> >> pgpool-general mailing list
>> >> pgpool-general at pgpool.net
>> >> http://www.pgpool.net/mailman/listinfo/pgpool-general
>> >>
>> >
>> > _______________________________________________
>> > pgpool-general mailing list
>> > pgpool-general at pgpool.net
>> > http://www.pgpool.net/mailman/listinfo/pgpool-general
>> _______________________________________________
>> pgpool-general mailing list
>> pgpool-general at pgpool.net
>> http://www.pgpool.net/mailman/listinfo/pgpool-general
>>