On Mon, Dec 3, 2012 at 5:14 PM, Wietse Venema <wie...@porcupine.org> wrote: > Dan Lists: > [ Charset ISO-8859-1 unsupported, converting... ] >> On Fri, Nov 30, 2012 at 1:49 PM, Wietse Venema <wie...@porcupine.org> wrote: >> > Dan Lists: >> >> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up >> >> passwd info for user: Invalid argument >> > >> > The getpwnam_r() SYSTEM LIBRARY ROUTINE reports an error, >> > with errno set to EINVAL (Invalid argument). >> > >> > Find out why the SYSTEM LIBRARY ROUTINE reports this error. >> > >> >> If the user name is longer that 16 chars and the user does not exist, >> getpwnam_r() returns EINVAL. If the user exists, it works fine >> regardless of the length. I saw a report of this same behavior with >> dovecot. There is a patch to dovecot to fix it. > > Why not submit a fix to have getpwnam_r fixed instead? If a system > library function returns an undefined error code, then that is a BUG. > >> Does postfix need to treat the EINVAL as if the user does not exist? >> Is there a way to change the behavior of getpwnam*? > > EINVAL is not a documented result code. > http://pubs.opengroup.org/onlinepubs/009695399/functions/getpwnam.html > > Postfix is built accoirding to standards, not by tinkering with > library calls and guessing what the result means. > > Wietse
I just ran my test program on FreeBSD 7.3, and it has the same result as on FreeBSD 8.3: Looking up: doesnotexistXXXX Returned no result! Looking up: doesnotexistXXXXy Return code: 22 It was working on FreeBSD 7.3 with postfix 2.8.7, and it is not working on FreeBSD 8.3 with postfix 2.9.3. Since the behavior of getpwnam_r is the same between the OS versions, it seems likely that some change between postfix 2.8.7 and 2.9.3 is causing postfix to react differently to getpwnam_r returning EINVAL. I downgraded postfix from 2.9.3 to 2.8.11 on the FreeBSD 8.3 box and everything works as expected.
