On Tue, Dec 4, 2012 at 5:48 AM, Wietse Venema wie...@porcupine.org wrote:
Taking a quick look at the source, it looks like 2.8 does not use the
thread-safe getpwnam_r. It does not appear that postfix is threaded,
so it should be safe to not use getpwnam_r.
It has NOTHING TO TO WITH THREADS.
Dan Lists:
It has NOTHING TO TO WITH THREADS.
In particular, getpwnam() on top of *SQL etc. return null (i.e.
user not found) when the database is unavailable. There is no
official API for getpwnam() to indicate I don't know because
getpwnam() is not supposed to return in such cases.
As
On Wed, Dec 5, 2012 at 11:55 AM, Wietse Venema wie...@porcupine.org wrote:
I will not base Postfix development on UNDOCUMENTED return values.
That is unmaintainable.
I've brought it up on the FreeBSD lists. I suggested that it is a bug
for getpwnam_r to act the way it is. I'll probably end
Dan Lists:
On Wed, Dec 5, 2012 at 11:55 AM, Wietse Venema wie...@porcupine.org wrote:
I will not base Postfix development on UNDOCUMENTED return values.
That is unmaintainable.
I've brought it up on the FreeBSD lists. I suggested that it is a bug
for getpwnam_r to act the way it is.
Dan Lists:
Postfix avoids using using getpwnam() because it is fundamentally
broken on lots of systems (reporting user does not exist after
failure to complete the request).
You can force Postfix to use getpwnam() if you know that you
will never use *SQL or LDAP etc. datbases:
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
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
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
Dan Lists:
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,
On Mon, Dec 3, 2012 at 7:42 PM, Wietse Venema wie...@porcupine.org wrote:
Dan Lists:
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.
, dsn=4.0.0, status=deferred (user lookup error)
Because it is a temporary error, it keeps trying over and over. In
the case of aliases, the valid recipients get a copy each time it
retries.
Delivery to users that exist works fine. IMAP and POP work fine. All
other system functions work fine
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.
Because
12 matches
Mail list logo