Bug 2555 - Samba hangs with postgres backend
Samba hangs with postgres backend
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control
x86 Linux
: P3 major
: none
Assigned To: Jelmer Vernooij
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2005-03-29 06:19 UTC by Fernando Schapachnik
Modified: 2005-08-24 10:19 UTC (History)
1 user (show)

See Also:

Correct SQL usage in various ways (13.76 KB, patch)
2005-04-07 06:23 UTC, Fernando Schapachnik
no flags Details
Correct SQL usage in various ways (improved) (18.44 KB, patch)
2005-04-14 05:59 UTC, Fernando Schapachnik
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fernando Schapachnik 2005-03-29 06:19:52 UTC
On a reasonable big domain (~800 users), using postgres as a backend on a RHES 3
dual processor, Samba hangs after a while. This is Samba 3.0.{11,12}, compiled
from source. The problem goes away using the smbpasswd backend.

The symptom is that at the beginning everything works fine, but after a while
(generally aprox. 1 hour), the number of smb processes start to climb from ~20
to ~100 or more, and don't die with regular kill. At this point, all domain
activity stops, even though the database log shows that there are still some
queries going on (maybe already stablished connections?).

Samba logs do not show any error (log level 3), and neither the database.

I have an lsof capture at the time of the problem, but not sure what to look up
for in there.
Comment 1 Fernando Schapachnik 2005-03-29 06:46:50 UTC
New info, not sure if related or not: at some point, the samba logs show:

[2005/03/28 13:30:07, 0] passdb/pdb_pgsql.c:pgsqlsam_select_by_field(251)
  Error executing SELECT
FROM sso.samba WHERE username = 'XXXXXXXXXXXX', ERROR:  parser: parse error at
or near "WHERE" at character 22

But the corresponding entry in the postgres logs do not flag the query as error
(it actually executes OK when pasted).

Comment 2 Fernando Schapachnik 2005-03-29 07:12:43 UTC
The postgres log doesn't show the error, because it actually corresponds to
another, previous query:
2005-03-28 13:38:21 [12979]  LOG:  query: UPDATE sso.samba SET WHERE user_sid =
2005-03-28 13:38:21 [12979]  ERROR:  parser: parse error at or near "WHERE" at
character 22

This might (just speculating here) be related to the 3.0.12 Release Notes item:
   * BUG 1957: Implement minimal update of fields in mySQL pdb 

But the hanging problem was first seen with 3.0.11 (when this messages didn't
appear), so might not be related to this.
Comment 3 Fernando Schapachnik 2005-03-30 09:11:36 UTC
It seems the way Samba is handling the connection to postgres is wrong. Please
take a look at my post to the postgres mailing list to check that my description
is accurate:


Comment 4 Fernando Schapachnik 2005-04-07 06:23:57 UTC
Created attachment 1143 [details]
Correct SQL usage in various ways

Two problems were solved:

-BUG 1957 correction introduced situations where Samba would issue an "UPDATE
table SET WHERE user='XXX'" (notice the absence of condition). See
sql_account_query_update(), which now returns NULL if no field was changed.
This was also corrected for mysql, although not tested.

-A single connection shared among many processes is not correct per libpq docs.
So I made it connect, issue a command and disconnect. This is not optimal,
although now it works correctly. I'm planning on building a connection pool
version, but I'm still not familiar on the mutex mechanisms prefered by Samba.
Would apreciate some advice on that.

-Warning. The patch also includes BUG 2334 patch, and probably obsoletes BUG
2348 (not tested yet).
Comment 5 Fernando Schapachnik 2005-04-07 06:24:37 UTC
Forgot to mention: the patch is against 3.0.13.
Comment 6 Fernando Schapachnik 2005-04-14 05:59:56 UTC
Created attachment 1153 [details]
Correct SQL usage in various ways (improved)

This patch improves the previous one by using one connection per Samba process
(versus one connection per query).

Both the master process and each child get their own connection.
Comment 7 Fernando Schapachnik 2005-06-21 04:51:50 UTC
The fixes has recently been commited.
Comment 8 Gerald (Jerry) Carter 2005-08-24 10:19:38 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.