I'm making this post here in hopes I may save someone from beating
their head against the wall like I did...
I am writing a custom Name Service Switch (NSS) module to take
advantage of already existing account information in a pg database.
Under certain circumstances, processes will hang due to non-recursive
mutex locking during PG connection creation. It goes something like
this:
========================================
/etc/nsswitch.conf:
passwd: files mypgmod
group: files mypgmod
========================================
[process with euid not found in /etc/passwd, looking up another
username not found in /etc/passwd]
getpwnam_r(username, ...)
// nss doesn't find user in files module (/etc/passwd),
// so uses mypgmod
_nss_mypgmod_getpwnam_r(username, ...)
pthread_mutex_lock(...) //to protect PG connection, then...
PQconnectdb(...)
// any number of reasons to look up info in calling user's
// home directory, e.g., default password, ssl certs, etc.,
// resulting in call to getpwuid_r() to find user's homedir.
getpwuid_r(geteuid(), ...)
// nss doesn't find user in files module (/etc/passwd),
// so uses mypgmod
_nss_mypgmod_getpwuid_r(uid, ...)
pthread_mutex_lock(...) //to protect PG connection
/* HANG */
* * *
The "fix," if you can call it that, is to run nscd, the NSS caching
daemon. Typically run as root (with account info in /etc/passwd) the
second lookup will not generate a second connection attempt.
Also, there exists in many linux distros a libnss-pgsql2 package which
suffers from the exact same problem (there are some scattered posts on
the 'net about it). Same "fix" ... run nscd.
Cheers,
Daniel Popowich
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
