[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Un cambio en Senmail (quizas no muy reciente)



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.    acastro@ctv.es |    
+()()()----------()()()--------------------------+  



Reply to: