On 4.3.2011, at 22.31, Douglas Mortensen wrote: > This morning on our newly built server, the following was logged twice: > auth: Error: pam(username,127.0.0.1): pam_authenticate() failed: > Authentication failure (/etc/pam.d/dovecot missing?) > > This also happened to be during a time of 100+ imap-login processes, where we > were seeing: > master: Warning: service(imap-login): process_limit reached, client > connections are being dropped
This should be irrelevant. If this error goes away, do you still get that pam failure? > In looking at pam documentation, it is my understanding that when a service > (dovecot) does not have its own file existing under /etc/pam.d, then pam will > instead use the settings from /etc/pam.d/others as defaults. It does? I don't know. It suggests checking pam.d/dovecot file, because that has been the most common reason why it hasn't worked for some people. Maybe they didn't have the others file either. > This seems logical to me, and would explain why things have been working > fairly well with no errors regarding pam (other than the 2 logged this > morning). However, what this does not explain, is why dovecot auth logged > about the file missing at all. It logged it only as a guess. > I can only guess that it was related to logins being dropped due to high > load, and was incorrectly logged?? The reason for the authentication failure could be anything. Dovecot doesn't know, because PAM doesn't tell. PAM has its own (crappy) logging, maybe it has something? > For reference, my current /etc/pam.d/dovecot is: > auth required pam_unix.so nullok > account required pam_unix.so So /etc/shadow.. High load shouldn't really affect that. In any case, PAM gave Dovecot authentication failure, and there's not much I can do to guess reasons why that happened. Either PAM logged a more specific error message, or it didn't. You could always try not using PAM at all, then you'll get Dovecot's own awesome error logging that tells exactly what goes wrong.
