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