Le 18 févr. 2013 à 06:21, Timo Sirainen tss@iki.fi a écrit :
On Sun, 2013-02-17 at 12:24 +0100, Axel Luttgens wrote:
Le 17 févr. 2013 à 05:47, Timo Sirainen a écrit :
[...] The gethostbyname() call is used to figure out the current system's domain. Why it would be hanging there, I don't really know. That call anyway isn't fully required, you could just replace it with "hent = NULL;"
Yes, looks like those gethostbyname() require some investigations here... I'll have a look and provide my "findings" here.
Very modest findings; anyway, here they are, should they be of some help for nailing the causes down.
First, having the db query returning only a virtual uid (eg, 100002), thus making use of a system group set with mail_gid (e.g., 999), those hangs do not occur anymore.
On the other hand, this quick one:
#include <syslog.h>
#include <netdb.h>
#define NULL ((void *)0)
int main( int argc, const char * argv[])
{
struct hostent *hent;
hent = gethostbyname("ALMba.local");
if ( hent != NULL )
{
syslog(LOG_NOTICE|LOG_MAIL, "name returned by gethostbyname(): %s\n", hent->h_name);
}
return(0);
}
compiled as ghbn and with perms set to:
-rwsr-sr-x 1 100002 100002 8816 18 fév 09:08 ghbn
doesn't hang and yields:
[ASLMessageID 385162] [Time 1361175967] [TimeNanoSec 451292000] [Level 5] [PID 5616] [UID 100002] [GID 100002] [ReadGID 80] [Host ALMba.local] [Sender ghbn] [Facility mail] [Message name returned by gethostbyname(): almba.local]
It could thus be inferred that the problems encountered here are related to virtual gids only when setting up child processes from within Dovecot. Don't know whether this impacts those calls to gethostbyname() only, or if other side-effects may be expected as well.
Now, would all this be a Mac OS X thing only? Or are such problems liable to occur on other platforms as well?
In the meantime, I don't really like the idea of messing with a general purpose function, my_hostdomain(), just to avoid a local problem... Wouldn't you have a better idea? ;-)
Solution for v2.2: http://hg.dovecot.org/dovecot-2.2/rev/a6b40687c0a4
Wow, that's a good idea. :-) This should indeed circumvent those hangs, but also avoid many rather costly system calls.
It seems it could be easily back ported to 2.1.x. I'll try and report back here.
Many thanks, Axel