Bueno pues por fin he resuelto el problema con sendmail.

Puesto que nadie de la lista ha sabido darme ninguna
pista sobre el particular mando esto para resaltar que
efectivamente parece que hay un comportamiento distinto
de sendmail con versiones anteriores. El problema quizas
venga por una mala configuraci�n m�a que anteriormente no
me daba problemas. Recuerdo que el problema consist�a en 
que sendmail tardaba un minuto exacto en empezar a hacer 
cualquier cosa. Incluso mailq tardaba un minuto.
/etc/resolv.conf parec�a no tener que ver.

As� las cosas decid� investigar el tema por mi mismo hasta
donde pudiera y luego con el m�ximo de d�tos llamar a
Luis Ignacio para que me ayudara.

Empiezo por ejecutar mailq con el strace.

================================================================
# strace mailq
connect(3, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = -1 EPROTOTYPE 
(Protocol wrong type for socket)
close(3)                                = 0
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
connect(3, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = 0
send(3, "<18>Oct 16 19:54:10 sendmail[961"..., 101, 0) = 101
sigaction(SIGPIPE, {SIG_IGN}, NULL)     = 0
sigprocmask(SIG_BLOCK, [ALRM], [])      = 0
time([908560450])                       = 908560450
getpid()                                = 9618
sigaction(SIGALRM, {0x804c2a0, [], 0}, {SIG_DFL}) = 0
alarm(60)                               = 0
sigprocmask(SIG_UNBLOCK, [ALRM], [ALRM]) = 0
sigprocmask(SIG_UNBLOCK, [ALRM], [])    = 0
pause(
=====================================================================

Despu�s busco en los fuentes de sendmail. (8.8.6)
En clock.c localizo lo que parece una implementaci�n de sleep con ala
Y en otro fuente busco    sleep(60)


==daemon.c===========================================================
 **  If _still_ no dot, wait for a while and try again -- it is
 **  possible that some service is starting up.  This can result
 **  in excessive delays if the system is badly configured, but
 **  there really isn't a way around that, particularly given that
 **  the config file hasn't been read at this point.
 **  All in all, a bit of a mess.
 */

 if (strchr(hostbuf, '.') == NULL && !getcanonname(hostbuf, size, TRUE))
    {
     sm_syslog(LOG_CRIT, NOQID,
           "My unqualified host name (%s) unknown; sleeping for retry",
            hostbuf);
     message("My unqualified host name (%s) unknown; sleeping for retry",
            hostbuf);
            sleep(60);
            if (!getcanonname(hostbuf, size, TRUE))
            {
                sm_syslog(LOG_ALERT, NOQID, "unable to qualify my own"
                         "domain name (%s) -- using short name", hostbuf);
                message("WARNING: unable to qualify my own domain"
                         " name (%s) -- using short name",
===========================================================================


Llegado aqu� se me ocurre repetir mailq y buscar el mensaje en 
/var/log/... y Bingo. 


=======/var/log/mail.log==================================================
nknown; sleeping for retry
Oct 16 19:38:29 localhost sendmail[9571]: My unqualified host name (localhost) 
unknown; sleeping for retry
Oct 16 19:50:00 localhost sendmail[9607]: My unqualified host name (localhost) 
unknown; sleeping for retry
Oct 16 19:51:00 localhost sendmail[9607]: unable to qualify my own domain name 
(localhost) -- using short name
===========================================================================


Bueno seguro que llegado a este punto algu�en se preguntar� porque en 
lugar de dar tantas vueltas no empec� mirando directamente /var/log/mail.log
La respuesta es que no lo vi. Busque en el lugar equivocado /var/log/messages
En este punto fu� cuando recurro a Luis Ignacio.

===/etc/hosts==============================================================
127.0.0.1       localhost            midas
172.22.22.22    tintin.ctv.es        tintin
172.22.22.21    midas.ctv.es         midas
172.22.22.23    robin.ctv.es         robin
===========================================================================

Por indicaci�n de Luis Ignacio elimino el �ltimo campo (alias=midas) de 
la primera linea y todo vuelve a funcionar perfectamente.

A mi no me pregunteis porque funciona ahora. Luis solo me ha podido
decir que esa pr�ctica de poner un alias a localhost no es buena
pero tampoco �l sabe con exactitud la raz�n de este comportamiento
de sendmail. Parece que intenta averiguar el dominio de la m�quina
y la configuraci�n de /etc/hosts no se como terminaba despistandole.
Esto no pasaba en la versi�n de sendmail que yo usaba antes.

No es un bug pero creo interesante lanzar este aviso porque es
facil que alguien m�s tenga ese mismo problema ya que poner un
alias a locahost es algo que creo haber visto como pr�ctica recomendable
en alg�n sitio aunque no recuerdo donde. Bueno ahora creo que no lo es.
Puede que alguno me diga que no me entero y que este cambio ya es viejo
pero yo me entero ahora y en cuanto a la renovaci�n de versiones no
acostumbro a hacer m�s de un cambio general al a�o. En lo sucesivo quizas
tarde algo m�s.

Espero haber sido util aunque no estoy muy seguro de ello.


---------------------------------------------------------------------------
En caso de contestar a la lista mandame copia personal.

        /\     /\  Los mas importantes desarrolladores de Bases de datos 
          \\W//    est�n portando sus productos a Linux. Porque crees tu
         _|0 0|_   que ser� ?    Yo creo que Linux es el futuro.
+-oOOO--(___o___)--OOOo--------------------------+ 
|  . . . . U U . . . . Antonio Castro Snurmacher |  
| http://slug.ctv.es/~acastro.    [EMAIL PROTECTED] |    
+()()()----------()()()--------------------------+  

Responder a