Database connections not being closed about sympa HOT 10 CLOSED

Have just started myEaster break so will do a more of the above in a day or two.

sympa.x86_64 6.2.16-1.20160920.svn12962.RHEL6

It has been awhile since I last looked at this but the issue still exists so I thought I had better spend some more time on it. I am currently running sympa-6.2.22-1.20171002.RHEL6.x86_64 on CentOS 7 with postgresql-libs-9.2.23-1.el7_4.x86_64 on the front end against postgresql96-server-9.6.6-1PGDG.rhel7.x86_64 on the backend DB server. I have had a cron job that watches until the number of sympa connections reaches 100 then kills most of them. This has prevented the services dying and our DB server running out of available connections. With statement logging turned on, it seems that the process leakage always opens a connection and performs a single query Feb 17 12:52:08 agree-12 postgres[13527]: [26-1] sympa6/sympa [2001:df0:dc::251:25] LOG: execute dbdpg_p14861_10: SELECT bounce_subscriber AS "bounce", bounce_address_subscriber AS "bounce_address", bounce_score_subscriber AS "bounce_score", custom_attribute_subscriber AS "custom_attribute", date_part('epoch',date_subscriber) AS "date", user_subscriber AS "email", suspend_end_date_subscriber AS "enddate", comment_subscriber AS "gecos", include_sources_subscriber AS "id", included_subscriber AS "included", number_messages_subscriber AS "number_messages", reception_subscriber AS "reception", suspend_start_date_subscriber AS "startdate", subscribed_subscriber AS "subscribed", suspend_subscriber AS "suspend", topics_subscriber AS "topics", date_part('epoch',update_subscriber) AS "update_date", visibility_subscriber AS "visibility" Feb 17 12:52:08 agree-12 postgres[13527]: [26-2] #11 FROM subscriber_table Feb 17 12:52:08 agree-12 postgres[13527]: [26-3] #11 WHERE list_subscriber = 'list-owners' AND robot_subscriber = 'godzone.net.nz' ORDER BY email Feb 17 12:52:08 agree-12 postgres[13527]: [27-1] sympa6/sympa [2001:df0:dc::251:25] LOG: statement: DEALLOCATE dbdpg_p14861_10 In some case, that same connection is later re-used but in others it doesn’t and a new connection gets opened without closing the existing one. SO I am guessing that whatever is returned somehow effects the logic in the calling SYMPA process. 1396 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(51598) idle 2837 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(51672) idle 13201 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(50488) idle 13527 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(50506) idle 14294 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(50550) idle 18939 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(50772) idle 22473 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(50960) idle 22482 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(50962) idle 24264 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(51050) idle 29663 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(51314) idle 32443 ? Ss 0:00 postgres: sympa sympa6 2001:df0:dc::251:25(51538) idle I am not sure how to go about tracking this down or even which of the sympa processes is doing the work, I think it is task_manager but I am only guessing -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph +64 6 357 8168, Mob +64 27 542 4015 “Specialising in providing low-cost professional Internet Services since 1997"