getpwnam() failed: Resource temporarily unavailable
Hi,
I see a very peculiar Dovecot (2.3.21.1) authentication failure that concerns exactly one user:
Aug 20 02:08:05 Bounce dovecot: auth-worker(13245): Debug: conn unix:auth-worker (pid=3029,uid=81): auth-worker<24>: Handling PASSV request Aug 20 02:08:05 Bounce dovecot: auth-worker(13245): Debug: conn unix:auth-worker (pid=3029,uid=81): auth-worker<24>: passwd(REDACTED_UID,84.136.89.217,<yZxQxMA8uL1UiFnZ>): Performing passdb lookup Aug 20 02:08:05 Bounce dovecot: auth-worker(13245): Debug: conn unix:auth-worker (pid=3029,uid=81): auth-worker<24>: passwd(REDACTED_UID,84.136.89.217,<yZxQxMA8uL1UiFnZ>): lookup Aug 20 02:08:05 Bounce dovecot: auth-worker(13245): Error: conn unix:auth-worker (pid=3029,uid=81): auth-worker<24>: passwd(REDACTED_UID,84.136.89.217,<yZxQxMA8uL1UiFnZ>): getpwnam() failed: Resource temporarily unavailable Aug 20 02:08:05 Bounce dovecot: auth-worker(13245): Debug: conn unix:auth-worker (pid=3029,uid=81): auth-worker<24>: passwd(REDACTED_UID,84.136.89.217,<yZxQxMA8uL1UiFnZ>): Finished passdb lookup Aug 20 02:08:05 Bounce dovecot: auth-worker(13245): Debug: conn unix:auth-worker (pid=3029,uid=81): auth-worker<24>: Finished: internal_failure
This used to work, until a few months ago it stopped. The user can still authenticate to send mail through the same server. Changing the password didn't make a difference.
Any ideas?
Cheerio, Hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On Wed, 2025-08-20 at 12:33 +0200, Hauke Fath via dovecot wrote:
getpwnam() failed: Resource temporarily unavailable
hiya
EAGAIN failure from getpwnam() seems quite odd to me - especially if it only happens with one username.
A quick glance at current dovecot git source did not help my understanding. I can see how errno could be ENOMEM, EINVAL or ERANGE, but not really EAGAIN.
Is it possible the errno came from elsewhere somehow? Does this have auth_debug = yes? Any chance you can run a test with current release 2.4.1 or git head to see if it exhibits similar issues?
Not a dovecot dev, but if were me and debug logs did not reveal enough, I'd add some debugging print statements to src/lib/ipwd.c (thats where the 2.4.x call to getpwnam_r() is) to try figure out what is actually happening. I did not look to see how similar the old 2.3.x code is to 2.4.
Aki can likely offer real insight.
-- Gene
On 8/20/25 14:49, Genes Lists via dovecot wrote:
Is it possible the errno came from elsewhere somehow?
The error is reproducible, and only happens with this account (in ~6 weeks of log files). For this account, it happens from different client machines, and MUAs.
Does this have auth_debug = yes?
Yes, hence the verbosity.
Any chance you can run a test with current release 2.4.1 or git head to see if it exhibits similar issues?
It's a production machine. And since the recent comments here give me the impression that 2.4 should really have been called 3.0 Alpha, I think I'll pass.
Not a dovecot dev, but if were me and debug logs did not reveal enough, I'd add some debugging print statements to src/lib/ipwd.c (thats where the 2.4.x call to getpwnam_r() is) to try figure out what is actually happening. I did not look to see how similar the old 2.3.x code is to 2.4.
Thanks, I'll have a look at the code.
Cheerio, Hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 20/08/2025 14:49, Genes Lists via dovecot wrote:
On Wed, 2025-08-20 at 12:33 +0200, Hauke Fath via dovecot wrote:
getpwnam() failed: Resource temporarily unavailable hiya
EAGAIN failure from getpwnam() seems quite odd to me - especially if it only happens with one username.
A quick glance at current dovecot git source did not help my understanding. I can see how errno could be ENOMEM, EINVAL or ERANGE, but not really EAGAIN.
I think that ERANGE is not possible since the code in i_getpwnam() loops until it gets a different errno.
Any errno different to ERANGE and EINVAL returned by the call to getpwnam_r() will end up being logged so long as no result is returned. So if EAGAIN is returned then then that will get loggged (and depending on the library implementation that may also cover EWOULDBLOCK) . If a result is returned then that is taken without checking for errno. EINVAL is not possible as the code maps it to a non error condition.
Is it possible the errno came from elsewhere somehow?
In theory yes, since the errno is not actually saved and between the getpwnam_r() call and the error being logged there are some other system calls that could potentially change errno value. However I don't believe the odds of this happening are particularly high.
Does this have auth_debug = yes? Any chance you can run a test with current release 2.4.1 or git head to see if it exhibits similar issues?
Not a dovecot dev, but if were me and debug logs did not reveal enough, I'd add some debugging print statements to src/lib/ipwd.c (thats where the 2.4.x call to getpwnam_r() is) to try figure out what is actually happening. I did not look to see how similar the old 2.3.x code is to 2.4.
Also the OP could construct a small test program of a few lines to call getpwnam_r and see whether the behaviour for this user lookup can be reproduced independently of Dovecot. Another idea is to look into how the system is configured to resolve calls to getpwnam_r, e.g. nsswitch.conf if this is linux/unix or similar.
John
Aki can likely offer real insight.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
participants (3)
-
Genes Lists
-
Hauke Fath
-
John Fawcett