This one time, at band camp, martin f krafft said:
> I have since found #267548 and ran an ltrace, which shows the
> hanging command to be
>
> [...]
> getpwent(0x804b4c5, 0x8050540, 0x8050549, 105, 108)
> = 0xb7f41cf0
> printf("%s:%s:%lu:%lu:%s:%s:%s\n", "postgres", "x", 106, 109,
> "PostgreSQL administrator,,,", "/var/lib/postgresql",
> "/bin/bash"postgres:x:106:109:PostgreSQL
> administrator,,,:/var/lib/postgresql:/bin/bash
> ) = 77
> getpwent(0x804b4c5, 0x8050540, 0x8050549, 106, 109[hangs here]
>
> Still clueless...
The nss routines in nss-psql appear to be not completely thread safe.
My best guess of what is happening is that user krafft does something
that causes an nss lookup. This fails to find an entry in passwd, and
consults postgres. postgres has an ident sameuser line in pg_hba.conf,
triggering an nss lookup. Both of these events attempt to modify
something in the same process space without proper mutex locking, and
you get a futex deadlock.
FWIW, we've recently moved alioth to using nss_updatedb as a result of
symptoms exactly like this. Various people have talked about working
with the new upstream version of nss-pgsql to see if it does any better,
but I don't know if they have working packages yet.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature