J'ai un serveur de messagerie sous Linux Suse 8.1, avec Sendmail
8.12.6...
Mon problème est le suivant...au bout d'un certain temps, mon sendmail
plante et n'accepte plus de connexion (en parallèle, mon robot
IPSentry qui scanne cette machine, me la met "UP" et "DOWN" à chaque
interrogation :-(....)
a chaque fois que le sendmail est planté (dixit mon robot), je regarde
les process et voila en gros ce que j'obtiens :
# ps aux |grep mail
==>
root 23113 0.0 0.2 5596 616 ? S Apr07 0:24
sendmail: rejecting connections on daemon MTA: 25 children, max 25
mail 23117 0.0 0.1 5392 312 ? S Apr07 0:00
sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue
root 9526 0.0 1.4 8368 3616 ? S Apr07 0:05
sendmail: ./i35NZHrs030769 gunnm-seraphim.org.: user open
root 12311 0.0 1.1 7912 3000 ? S Apr07 0:02
sendmail: ./i37BZxkr013989 from queue
root 13799 0.0 1.2 7376 3180 ? S Apr07 0:02
sendmail: ./i37Chfkr019173 gateway.net.: user open
root 15031 0.0 1.3 8132 3552 ? S Apr07 0:03
sendmail: ./i363cBrs018106 from queue
root 16329 0.0 1.2 7276 3128 ? S Apr07 0:02
sendmail: ./i37Colkr019610 swbell.com.: user open
root 18018 0.0 1.2 8320 3136 ? S 00:03 0:05
sendmail: ./i363ZJrs017929 gateway.net.: user open
root 19394 0.0 1.3 7856 3468 ? S 00:33 0:01
sendmail: ./i37BCYkr012119 btw.com.: user open
root 20685 0.0 1.3 7916 3500 ? S 01:03 0:01
sendmail: ./i360pPrs004054 qualty.com.: user open
root 21747 0.0 0.8 7884 2240 ? S 01:33 0:01
sendmail: ./i35NMcrs029713 news.earthlink.net.: user open
root 22784 0.0 1.3 7928 3456 ? S 02:03 0:01
sendmail: ./i360FTrs001280 gateway.net.: user open
root 23736 0.0 1.1 7748 2828 ? S 02:33 0:01
sendmail: ./i36Gfn4L031986 from queue
root 24800 0.0 1.0 7656 2744 ? S 03:03 0:01
sendmail: ./i361sVrs010352 from queue
root 26005 0.0 0.7 7656 2028 ? S 03:33 0:01
sendmail: ./i37CGMkr016977 ccapitalc.com.: client greeting
root 27147 0.0 1.1 7728 2892 ? S 04:03 0:01
sendmail: ./i37Arukr010936 from queue
root 28508 0.0 1.1 7708 2956 ? S 04:33 0:01
sendmail: ./i37CCQkr016660 bookmarkpublishing.com.: user open
root 29434 0.0 1.1 7660 2968 ? S 05:03 0:01
sendmail: ./i363JJrs016452 from queue
root 30217 0.0 1.1 7172 2864 ? S 05:33 0:01
sendmail: ./i36GMj4L030730 pissed.com.: client greeting
root 31083 0.0 1.0 6980 2704 ? S 06:03 0:00
sendmail: ./i363Bers015874 mail.perl.com.: user open
root 31843 0.0 1.1 7580 2868 ? S 06:33 0:00
sendmail: ./i36Guc4L000153 ixmail8.ix.netcom.com.: user open
root 32427 0.0 1.0 7496 2788 ? S 07:03 0:00
sendmail: ./i381JWkr025476 mta1-mail.england.com.: user open
root 258 0.0 1.0 7504 2780 ? S 07:33 0:00
sendmail: ./i37Anrkr010728 ixmail1.ix.netcom.com.: user open
root 755 0.0 1.0 7172 2644 ? S 08:03 0:00
sendmail: ./i381fikr026243 direcwave.com.: client greeting
root 888 0.0 0.9 6224 2336 ? S 08:15 0:00
sendmail: server scan3.softel.fr [194.51.246.33] cmd read
root 896 0.0 0.8 6224 2292 ? S 08:16 0:00
sendmail: server scan3.softel.fr [194.51.246.33] cmd read
Ok, je comprends bien qu'il essaie d'envoyer les mails en queue et que
ça répond pas mais pourquoi cela bloque les process ? ne devraient-ils
pas se "killer" au bout d'un moment ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thibaut Maquet
Bonjour,
tu as deux problèmes:
- tout d'abord Sendmail a trop de processus fils. (Maximum 25). Tu peux l'augmenter grâce à l'instruction M4 suivante: define(`confMAX_DAEMON_CHILDREN',`50')dnl
- tu sembles avoir beaucoup de connexions sortantes callées (stall), Sendmail a beaucoup de mal à faire l'expédition durant son cycle de dequeue, ce qui provoque la multiplication de ces processus fils d'où le premier problème. Tu peux tenter d'accélerer le transport en jouant par exemple sur les paramètres suivant: . Timeout.datablock qui est le délai d'attente d'un bloc d'information durant la phase DATA . Timeout.datafinal qui est le délai d'attente d'une réponse au point final ., qui détermine la fin d'un message. Ce qui se traduit en M4 comme suit: define(`confTO_DATABLOCK', `1m')dnl define(`confTO_DATAFINAL', `2m')dnl
Ce que je te conseille, c'est de te créer un sendmail.cf avec des paramètres un peu agressifs, avec tous les timeout à une minute par exemple, que tu lances la nuit, comme ceci: /usr/sbin/sendmail -C/etc/mail/sendmail-soir.cf -q
Maintenant un problème d'expédition n'est pas forcément lié à Sendmail, cela peut être tout simplement une surcharge de ta bande passante, un manque de ressource ou tout simplement que les MTA de destination ont des soucis. Cela arrive beaucoup plus souvent que ce que l'on peut croire.
Cordialement Thibaut Maquet www.pagasa.net (Livre sur Sendmail)
Bonjour,
tu as deux problèmes:
- tout d'abord Sendmail a trop de processus fils. (Maximum 25). Tu peux l'augmenter grâce
à l'instruction M4 suivante:
define(`confMAX_DAEMON_CHILDREN',`50')dnl
- tu sembles avoir beaucoup de connexions sortantes callées (stall), Sendmail a beaucoup de
mal à faire l'expédition durant son cycle de dequeue, ce qui provoque la multiplication
de ces processus fils d'où le premier problème.
Tu peux tenter d'accélerer le transport en jouant par exemple sur les paramètres suivant:
. Timeout.datablock qui est le délai d'attente d'un bloc d'information durant la phase DATA
. Timeout.datafinal qui est le délai d'attente d'une réponse au point final ., qui détermine la fin d'un message.
Ce qui se traduit en M4 comme suit:
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `2m')dnl
Ce que je te conseille, c'est de te créer un sendmail.cf avec des paramètres un peu agressifs, avec tous les
timeout à une minute par exemple, que tu lances la nuit, comme ceci:
/usr/sbin/sendmail -C/etc/mail/sendmail-soir.cf -q
Maintenant un problème d'expédition n'est pas forcément lié à Sendmail, cela peut être tout simplement
une surcharge de ta bande passante, un manque de ressource ou tout simplement que les MTA de
destination ont des soucis. Cela arrive beaucoup plus souvent que ce que l'on peut croire.
Cordialement
Thibaut Maquet
www.pagasa.net (Livre sur Sendmail)
- tout d'abord Sendmail a trop de processus fils. (Maximum 25). Tu peux l'augmenter grâce à l'instruction M4 suivante: define(`confMAX_DAEMON_CHILDREN',`50')dnl
- tu sembles avoir beaucoup de connexions sortantes callées (stall), Sendmail a beaucoup de mal à faire l'expédition durant son cycle de dequeue, ce qui provoque la multiplication de ces processus fils d'où le premier problème. Tu peux tenter d'accélerer le transport en jouant par exemple sur les paramètres suivant: . Timeout.datablock qui est le délai d'attente d'un bloc d'information durant la phase DATA . Timeout.datafinal qui est le délai d'attente d'une réponse au point final ., qui détermine la fin d'un message. Ce qui se traduit en M4 comme suit: define(`confTO_DATABLOCK', `1m')dnl define(`confTO_DATAFINAL', `2m')dnl
Ce que je te conseille, c'est de te créer un sendmail.cf avec des paramètres un peu agressifs, avec tous les timeout à une minute par exemple, que tu lances la nuit, comme ceci: /usr/sbin/sendmail -C/etc/mail/sendmail-soir.cf -q
Maintenant un problème d'expédition n'est pas forcément lié à Sendmail, cela peut être tout simplement une surcharge de ta bande passante, un manque de ressource ou tout simplement que les MTA de destination ont des soucis. Cela arrive beaucoup plus souvent que ce que l'on peut croire.
Cordialement Thibaut Maquet www.pagasa.net (Livre sur Sendmail)
glups
- tout d'abord Sendmail a trop de processus fils. (Maximum 25). Tu peux l'augmenter grâce à l'instruction M4 suivante: define(`confMAX_DAEMON_CHILDREN',`50')dnl Ok
(sendmail.cf => O MaxDaemonChildrenP)
Ce que je te conseille, c'est de te créer un sendmail.cf avec des paramètres un peu agressifs ok, c'est que je viens de faire (voila en gros mon sendmail.cf :
...mais mon robot me donne tjrs des "up and down" :-(
Maintenant un problème d'expédition n'est pas forcément lié à Sendmail, cela peut être tout simplement une surcharge de ta bande passante, un manque de ressource ou tout simplement que les MTA de
j'avoue y avoir pensé..la machine pourrait être à bloc (vu le spam et les virus qui circulent en ce moment !) mais la commande "top" ne me donne rien d'alarmant... (load average: 0.86, 0.74, 0.73)
Encore merci... Mary
- tout d'abord Sendmail a trop de processus fils. (Maximum 25). Tu peux l'augmenter grâce
à l'instruction M4 suivante:
define(`confMAX_DAEMON_CHILDREN',`50')dnl
Ok
(sendmail.cf => O MaxDaemonChildrenP)
Ce que je te conseille, c'est de te créer un sendmail.cf avec des paramètres un peu agressifs
ok, c'est que je viens de faire (voila en gros mon sendmail.cf :
...mais mon robot me donne tjrs des "up and down" :-(
Maintenant un problème d'expédition n'est pas forcément lié à Sendmail, cela peut être tout simplement
une surcharge de ta bande passante, un manque de ressource ou tout simplement que les MTA de
j'avoue y avoir pensé..la machine pourrait être à bloc (vu le spam et
les virus qui circulent en ce moment !)
mais la commande "top" ne me donne rien d'alarmant...
(load average: 0.86, 0.74, 0.73)
- tout d'abord Sendmail a trop de processus fils. (Maximum 25). Tu peux l'augmenter grâce à l'instruction M4 suivante: define(`confMAX_DAEMON_CHILDREN',`50')dnl Ok
(sendmail.cf => O MaxDaemonChildrenP)
Ce que je te conseille, c'est de te créer un sendmail.cf avec des paramètres un peu agressifs ok, c'est que je viens de faire (voila en gros mon sendmail.cf :
...mais mon robot me donne tjrs des "up and down" :-(
Maintenant un problème d'expédition n'est pas forcément lié à Sendmail, cela peut être tout simplement une surcharge de ta bande passante, un manque de ressource ou tout simplement que les MTA de
j'avoue y avoir pensé..la machine pourrait être à bloc (vu le spam et les virus qui circulent en ce moment !) mais la commande "top" ne me donne rien d'alarmant... (load average: 0.86, 0.74, 0.73)
Encore merci... Mary
Thibaut Maquet
Bonjour,
...mais mon robot me donne tjrs des "up and down" :-(
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ? Maintenant comme la durée de vie de tes message est de 5 jours, il faut attendre un peu pour voir comment cela va évoluer.
j'avoue y avoir pensé..la machine pourrait être à bloc (vu le spam et les virus qui circulent en ce moment !) mais la commande "top" ne me donne rien d'alarmant... (load average: 0.86, 0.74, 0.73)
Effectivement, tu as encore de la marge mais regardes aussi ton débit de bande passante. Ton problème est peut etre purement lié à la capacité de ta connexion. Maintenant afin de purger ta file d'attente, tu peux: - ramener temporairement ton queuereturn à 2 jours par exemple: define(`confTO_QUEUERETURN', `2d')dnl - faire un SMART_HOST sur le SMTP de ton provider de façon à t'affranchir des problématiques de dequeue et de requêtes MX: define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
Cordialement Thibaut Maquet www.pagasa.net (Livre sur Sendmail)
Bonjour,
...mais mon robot me donne tjrs des "up and down" :-(
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
Maintenant comme la durée de vie de tes message est de 5 jours, il faut
attendre un peu pour voir comment cela va évoluer.
j'avoue y avoir pensé..la machine pourrait être à bloc (vu le spam et
les virus qui circulent en ce moment !)
mais la commande "top" ne me donne rien d'alarmant...
(load average: 0.86, 0.74, 0.73)
Effectivement, tu as encore de la marge mais regardes aussi ton débit
de bande passante. Ton problème est peut etre purement lié à la
capacité de ta connexion.
Maintenant afin de purger ta file d'attente, tu peux:
- ramener temporairement ton queuereturn à 2 jours par exemple:
define(`confTO_QUEUERETURN', `2d')dnl
- faire un SMART_HOST sur le SMTP de ton provider de façon à
t'affranchir des problématiques de dequeue et de requêtes MX:
define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
Cordialement
Thibaut Maquet
www.pagasa.net (Livre sur Sendmail)
...mais mon robot me donne tjrs des "up and down" :-(
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ? Maintenant comme la durée de vie de tes message est de 5 jours, il faut attendre un peu pour voir comment cela va évoluer.
j'avoue y avoir pensé..la machine pourrait être à bloc (vu le spam et les virus qui circulent en ce moment !) mais la commande "top" ne me donne rien d'alarmant... (load average: 0.86, 0.74, 0.73)
Effectivement, tu as encore de la marge mais regardes aussi ton débit de bande passante. Ton problème est peut etre purement lié à la capacité de ta connexion. Maintenant afin de purger ta file d'attente, tu peux: - ramener temporairement ton queuereturn à 2 jours par exemple: define(`confTO_QUEUERETURN', `2d')dnl - faire un SMART_HOST sur le SMTP de ton provider de façon à t'affranchir des problématiques de dequeue et de requêtes MX: define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
Cordialement Thibaut Maquet www.pagasa.net (Livre sur Sendmail)
glups
bonjour,
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
oui...de façon aléatoire.. pr 9 03:12:32 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 03:13:01 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 04:36:55 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 04:44:52 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 .... Apr 9 06:00:46 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 06:01:13 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50
est-ce une bonne idée d'augmenter encore la valeur de MaxDaemonChildren...
Effectivement, tu as encore de la marge mais regardes aussi ton débit de bande passante. Ton problème est peut etre purement lié à la capacité de ta connexion.
nous somes centre hébergeur et avons 2 lignes de 4Mo...je crois pas que cela vienne de là...car mes lignes ne sont pas du tout à bloc...
Maintenant afin de purger ta file d'attente, tu peux: - ramener temporairement ton queuereturn à 2 jours par exemple: define(`confTO_QUEUERETURN', `2d')dnl
je viens de le modifier...ce matin, j'avais une liste plutot longue de "user open" (28 !):
S Apr08 0:06 sendmail: ./i35NFfrs029101 sbcglobal.com.: user open root 9580 0.0 1.5 8668 3980 ? S Apr08 0:07 sendmail: ./i35NZHrs030769 cgocable.net.: user open root 11092 0.0 1.2 8448 3320 ? S Apr08 0:06 sendmail: ./i35NAUrs028517 geom.umn.edu.: user open root 12569 0.0 1.3 8032 3452 ? S Apr08 0:03 sendmail: ./i360kjrs003746 ns1.qsl.net.: user open root 14101 0.0 1.3 8136 3368 ? S Apr08 0:03 sendmail: ./i35Mtrrs027407 fgh.com.: user open root 15511 0.0 1.2 7392 3244 ? S Apr08 0:03 sendmail: ./i363wOrs019441 mail.double.optinsites.net.: user open
problème de résolution de nom ?
- faire un SMART_HOST sur le SMTP de ton provider de façon à t'affranchir des problématiques de dequeue et de requêtes MX: define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
je suis moi meme le FAI...dans mon sendmail.cf, il est à vide...
J'ai pourtant d'autres serveurs avec autant sinon plus d'utilisateurs...et je n'ai pas ce probleme...je n'arrive pas a voir d'ou ça vient...
Merci de ton aide :-) Mary
bonjour,
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
oui...de façon aléatoire..
pr 9 03:12:32 perso sendmail[7909]: rejecting connections on daemon
MTA: 50 children, max 50
Apr 9 03:13:01 perso sendmail[7909]: rejecting connections on daemon
MTA: 50 children, max 50
Apr 9 04:36:55 perso sendmail[7909]: rejecting connections on daemon
MTA: 50 children, max 50
Apr 9 04:44:52 perso sendmail[7909]: rejecting connections on daemon
MTA: 50 children, max 50
....
Apr 9 06:00:46 perso sendmail[7909]: rejecting connections on daemon
MTA: 50 children, max 50
Apr 9 06:01:13 perso sendmail[7909]: rejecting connections on daemon
MTA: 50 children, max 50
est-ce une bonne idée d'augmenter encore la valeur de
MaxDaemonChildren...
Effectivement, tu as encore de la marge mais regardes aussi ton débit
de bande passante. Ton problème est peut etre purement lié à la
capacité de ta connexion.
nous somes centre hébergeur et avons 2 lignes de 4Mo...je crois pas
que cela vienne de là...car mes lignes ne sont pas du tout à bloc...
Maintenant afin de purger ta file d'attente, tu peux:
- ramener temporairement ton queuereturn à 2 jours par exemple:
define(`confTO_QUEUERETURN', `2d')dnl
je viens de le modifier...ce matin, j'avais une liste plutot longue de
"user open" (28 !):
S Apr08 0:06 sendmail: ./i35NFfrs029101 sbcglobal.com.:
user open
root 9580 0.0 1.5 8668 3980 ? S Apr08 0:07
sendmail: ./i35NZHrs030769 cgocable.net.: user open
root 11092 0.0 1.2 8448 3320 ? S Apr08 0:06
sendmail: ./i35NAUrs028517 geom.umn.edu.: user open
root 12569 0.0 1.3 8032 3452 ? S Apr08 0:03
sendmail: ./i360kjrs003746 ns1.qsl.net.: user open
root 14101 0.0 1.3 8136 3368 ? S Apr08 0:03
sendmail: ./i35Mtrrs027407 fgh.com.: user open
root 15511 0.0 1.2 7392 3244 ? S Apr08 0:03
sendmail: ./i363wOrs019441 mail.double.optinsites.net.: user open
problème de résolution de nom ?
- faire un SMART_HOST sur le SMTP de ton provider de façon à
t'affranchir des problématiques de dequeue et de requêtes MX:
define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
je suis moi meme le FAI...dans mon sendmail.cf, il est à vide...
J'ai pourtant d'autres serveurs avec autant sinon plus
d'utilisateurs...et je n'ai pas ce probleme...je n'arrive pas a voir
d'ou ça vient...
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
oui...de façon aléatoire.. pr 9 03:12:32 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 03:13:01 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 04:36:55 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 04:44:52 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 .... Apr 9 06:00:46 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50 Apr 9 06:01:13 perso sendmail[7909]: rejecting connections on daemon MTA: 50 children, max 50
est-ce une bonne idée d'augmenter encore la valeur de MaxDaemonChildren...
Effectivement, tu as encore de la marge mais regardes aussi ton débit de bande passante. Ton problème est peut etre purement lié à la capacité de ta connexion.
nous somes centre hébergeur et avons 2 lignes de 4Mo...je crois pas que cela vienne de là...car mes lignes ne sont pas du tout à bloc...
Maintenant afin de purger ta file d'attente, tu peux: - ramener temporairement ton queuereturn à 2 jours par exemple: define(`confTO_QUEUERETURN', `2d')dnl
je viens de le modifier...ce matin, j'avais une liste plutot longue de "user open" (28 !):
S Apr08 0:06 sendmail: ./i35NFfrs029101 sbcglobal.com.: user open root 9580 0.0 1.5 8668 3980 ? S Apr08 0:07 sendmail: ./i35NZHrs030769 cgocable.net.: user open root 11092 0.0 1.2 8448 3320 ? S Apr08 0:06 sendmail: ./i35NAUrs028517 geom.umn.edu.: user open root 12569 0.0 1.3 8032 3452 ? S Apr08 0:03 sendmail: ./i360kjrs003746 ns1.qsl.net.: user open root 14101 0.0 1.3 8136 3368 ? S Apr08 0:03 sendmail: ./i35Mtrrs027407 fgh.com.: user open root 15511 0.0 1.2 7392 3244 ? S Apr08 0:03 sendmail: ./i363wOrs019441 mail.double.optinsites.net.: user open
problème de résolution de nom ?
- faire un SMART_HOST sur le SMTP de ton provider de façon à t'affranchir des problématiques de dequeue et de requêtes MX: define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
je suis moi meme le FAI...dans mon sendmail.cf, il est à vide...
J'ai pourtant d'autres serveurs avec autant sinon plus d'utilisateurs...et je n'ai pas ce probleme...je n'arrive pas a voir d'ou ça vient...
Merci de ton aide :-) Mary
Thibaut Maquet
Bonjour,
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
oui...de façon aléatoire..
Ce n'est pas normal, cela devrait s'estomper.
est-ce une bonne idée d'augmenter encore la valeur de MaxDaemonChildren...
Tu peux, tant que ton Load Average n'explose pas.
Effectivement, tu as encore de la marge mais regardes aussi ton débit de bande passante. Ton problème est peut etre purement lié à la capacité de ta connexion.
nous somes centre hébergeur et avons 2 lignes de 4Mo...je crois pas que cela vienne de là...car mes lignes ne sont pas du tout à bloc...
Ok, hypothèse à écarter alors.
Maintenant afin de purger ta file d'attente, tu peux: - ramener temporairement ton queuereturn à 2 jours par exemple: define(`confTO_QUEUERETURN', `2d')dnl
je viens de le modifier...ce matin, j'avais une liste plutot longue de "user open" (28 !):
Oui cela me parait normal, il s'agit vraisemblablement des bounces, mais avec un TTL à deux jours, tout devrait s'accélerer et ton spool devrait se vider rapidement. Cela me fait quand même penser à du spam cette histoire. Tu es sûr qu'un de tes clients n'est pas relais ouvert derrière ton serveur ?
S Apr08 0:06 sendmail: ./i35NFfrs029101 sbcglobal.com.: user open root 9580 0.0 1.5 8668 3980 ? S Apr08 0:07 sendmail: ./i35NZHrs030769 cgocable.net.: user open root 11092 0.0 1.2 8448 3320 ? S Apr08 0:06 sendmail: ./i35NAUrs028517 geom.umn.edu.: user open root 12569 0.0 1.3 8032 3452 ? S Apr08 0:03 sendmail: ./i360kjrs003746 ns1.qsl.net.: user open root 14101 0.0 1.3 8136 3368 ? S Apr08 0:03 sendmail: ./i35Mtrrs027407 fgh.com.: user open root 15511 0.0 1.2 7392 3244 ? S Apr08 0:03 sendmail: ./i363wOrs019441 mail.double.optinsites.net.: user open
problème de résolution de nom ?
Non parce que la connexion SMTP est établie; si c'était un problème DNS, tu ne pourras même pas extraire le MX. L'important est de vider la queue. Tu peux voir son état grâce à mailstats. J'ai mis quelques infos ici: http://www.pagasa.net/mail/queue/queue.html
- faire un SMART_HOST sur le SMTP de ton provider de façon à t'affranchir des problématiques de dequeue et de requêtes MX: define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
je suis moi meme le FAI...dans mon sendmail.cf, il est à vide...
Ok, mais l'important est de vider la file d'attente, c'est là qu'est ton problème. Tu ne peux pas rebalancer tout le spool sur un serveur "tampon", temporairement ?
J'ai pourtant d'autres serveurs avec autant sinon plus d'utilisateurs...et je n'ai pas ce probleme...je n'arrive pas a voir d'ou ça vient...
Je pense que le mieux serait que tu graphes l'évolution de ton spool via MRTG, de façon à pouvoir determiner comment évolue la situation. Il est souvent difficile de tirer des conclusions en une seule journée à cause de la durée de vie des messages (D'où la modification du queue.return) Tu as peut être connu une poussée de spam, mais normalement des situations comme ceci ne durent pas, surtout si en temps normal, tu ne rencontres pas de tels problèmes. Je te préconise: - de bien vérifier que tu n'as pas un client qui te spamme en amont. - de faire un e2fsck sur ton /var (on ne sait jamais) - de vider ton spool sur un autre serveur via un SMART_HOST - de grapher ton spool de façon à voir comment évolue ta situation.
Tiens moi au courant. Cordialement Thibaut Maquet www.pagasa.net (Livre sur Sendmail)
Bonjour,
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
oui...de façon aléatoire..
Ce n'est pas normal, cela devrait s'estomper.
est-ce une bonne idée d'augmenter encore la valeur de
MaxDaemonChildren...
Tu peux, tant que ton Load Average n'explose pas.
Effectivement, tu as encore de la marge mais regardes aussi ton débit
de bande passante. Ton problème est peut etre purement lié à la
capacité de ta connexion.
nous somes centre hébergeur et avons 2 lignes de 4Mo...je crois pas
que cela vienne de là...car mes lignes ne sont pas du tout à bloc...
Ok, hypothèse à écarter alors.
Maintenant afin de purger ta file d'attente, tu peux:
- ramener temporairement ton queuereturn à 2 jours par exemple:
define(`confTO_QUEUERETURN', `2d')dnl
je viens de le modifier...ce matin, j'avais une liste plutot longue de
"user open" (28 !):
Oui cela me parait normal, il s'agit vraisemblablement des bounces,
mais avec un TTL à deux jours, tout devrait s'accélerer et ton
spool devrait se vider rapidement.
Cela me fait quand même penser à du spam cette histoire.
Tu es sûr qu'un de tes clients n'est pas relais ouvert derrière ton
serveur ?
S Apr08 0:06 sendmail: ./i35NFfrs029101 sbcglobal.com.:
user open
root 9580 0.0 1.5 8668 3980 ? S Apr08 0:07
sendmail: ./i35NZHrs030769 cgocable.net.: user open
root 11092 0.0 1.2 8448 3320 ? S Apr08 0:06
sendmail: ./i35NAUrs028517 geom.umn.edu.: user open
root 12569 0.0 1.3 8032 3452 ? S Apr08 0:03
sendmail: ./i360kjrs003746 ns1.qsl.net.: user open
root 14101 0.0 1.3 8136 3368 ? S Apr08 0:03
sendmail: ./i35Mtrrs027407 fgh.com.: user open
root 15511 0.0 1.2 7392 3244 ? S Apr08 0:03
sendmail: ./i363wOrs019441 mail.double.optinsites.net.: user open
problème de résolution de nom ?
Non parce que la connexion SMTP est établie; si c'était un problème
DNS, tu ne pourras même pas extraire le MX.
L'important est de vider la queue. Tu peux voir son état grâce à
mailstats. J'ai mis quelques infos ici:
http://www.pagasa.net/mail/queue/queue.html
- faire un SMART_HOST sur le SMTP de ton provider de façon à
t'affranchir des problématiques de dequeue et de requêtes MX:
define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
je suis moi meme le FAI...dans mon sendmail.cf, il est à vide...
Ok, mais l'important est de vider la file d'attente, c'est là qu'est ton
problème. Tu ne peux pas rebalancer tout le spool sur un serveur
"tampon", temporairement ?
J'ai pourtant d'autres serveurs avec autant sinon plus
d'utilisateurs...et je n'ai pas ce probleme...je n'arrive pas a voir
d'ou ça vient...
Je pense que le mieux serait que tu graphes l'évolution de ton spool via
MRTG, de façon à pouvoir determiner comment évolue la situation.
Il est souvent difficile de tirer des conclusions en une seule journée à
cause de la durée de vie des messages (D'où la modification du queue.return)
Tu as peut être connu une poussée de spam, mais normalement des situations
comme ceci ne durent pas, surtout si en temps normal, tu ne rencontres pas
de tels problèmes.
Je te préconise:
- de bien vérifier que tu n'as pas un client qui te spamme en amont.
- de faire un e2fsck sur ton /var (on ne sait jamais)
- de vider ton spool sur un autre serveur via un SMART_HOST
- de grapher ton spool de façon à voir comment évolue ta situation.
Tiens moi au courant.
Cordialement
Thibaut Maquet
www.pagasa.net (Livre sur Sendmail)
c'est quand même bizarre. As-tu toujours des "rejecting" dans tes logs ?
oui...de façon aléatoire..
Ce n'est pas normal, cela devrait s'estomper.
est-ce une bonne idée d'augmenter encore la valeur de MaxDaemonChildren...
Tu peux, tant que ton Load Average n'explose pas.
Effectivement, tu as encore de la marge mais regardes aussi ton débit de bande passante. Ton problème est peut etre purement lié à la capacité de ta connexion.
nous somes centre hébergeur et avons 2 lignes de 4Mo...je crois pas que cela vienne de là...car mes lignes ne sont pas du tout à bloc...
Ok, hypothèse à écarter alors.
Maintenant afin de purger ta file d'attente, tu peux: - ramener temporairement ton queuereturn à 2 jours par exemple: define(`confTO_QUEUERETURN', `2d')dnl
je viens de le modifier...ce matin, j'avais une liste plutot longue de "user open" (28 !):
Oui cela me parait normal, il s'agit vraisemblablement des bounces, mais avec un TTL à deux jours, tout devrait s'accélerer et ton spool devrait se vider rapidement. Cela me fait quand même penser à du spam cette histoire. Tu es sûr qu'un de tes clients n'est pas relais ouvert derrière ton serveur ?
S Apr08 0:06 sendmail: ./i35NFfrs029101 sbcglobal.com.: user open root 9580 0.0 1.5 8668 3980 ? S Apr08 0:07 sendmail: ./i35NZHrs030769 cgocable.net.: user open root 11092 0.0 1.2 8448 3320 ? S Apr08 0:06 sendmail: ./i35NAUrs028517 geom.umn.edu.: user open root 12569 0.0 1.3 8032 3452 ? S Apr08 0:03 sendmail: ./i360kjrs003746 ns1.qsl.net.: user open root 14101 0.0 1.3 8136 3368 ? S Apr08 0:03 sendmail: ./i35Mtrrs027407 fgh.com.: user open root 15511 0.0 1.2 7392 3244 ? S Apr08 0:03 sendmail: ./i363wOrs019441 mail.double.optinsites.net.: user open
problème de résolution de nom ?
Non parce que la connexion SMTP est établie; si c'était un problème DNS, tu ne pourras même pas extraire le MX. L'important est de vider la queue. Tu peux voir son état grâce à mailstats. J'ai mis quelques infos ici: http://www.pagasa.net/mail/queue/queue.html
- faire un SMART_HOST sur le SMTP de ton provider de façon à t'affranchir des problématiques de dequeue et de requêtes MX: define(`SMART_HOST',`esmtp:[smtp.de.ton.fai]')dnl
je suis moi meme le FAI...dans mon sendmail.cf, il est à vide...
Ok, mais l'important est de vider la file d'attente, c'est là qu'est ton problème. Tu ne peux pas rebalancer tout le spool sur un serveur "tampon", temporairement ?
J'ai pourtant d'autres serveurs avec autant sinon plus d'utilisateurs...et je n'ai pas ce probleme...je n'arrive pas a voir d'ou ça vient...
Je pense que le mieux serait que tu graphes l'évolution de ton spool via MRTG, de façon à pouvoir determiner comment évolue la situation. Il est souvent difficile de tirer des conclusions en une seule journée à cause de la durée de vie des messages (D'où la modification du queue.return) Tu as peut être connu une poussée de spam, mais normalement des situations comme ceci ne durent pas, surtout si en temps normal, tu ne rencontres pas de tels problèmes. Je te préconise: - de bien vérifier que tu n'as pas un client qui te spamme en amont. - de faire un e2fsck sur ton /var (on ne sait jamais) - de vider ton spool sur un autre serveur via un SMART_HOST - de grapher ton spool de façon à voir comment évolue ta situation.
Tiens moi au courant. Cordialement Thibaut Maquet www.pagasa.net (Livre sur Sendmail)
