[RESOLU] problème avec Fetchmail

[nidaime]

Bonjour,

Je tourne sous une SME 7.3 et récupère mes boite distante (pop3) par la contrib 'smeserver-fetchmail'.

Depuis 3 semaines, je rencontre le problème suivant:

- J'ai l'impression que certains emails (c'est aléatoire) ne sont pas supprimés du serveur distant et sont récupérés en un très grand nombre d'exemplaires (défois 250 emails similaires).

J'obtiens aussi le message (email) suivant sur le compte admin :

- (Cron Daemon) fetchmail: un autre fetchmail, au premier plan, est en exécution sur 32395.

Pour essayer de résoudre le problème, j'ai procédé aux dernières update de SME, désinstallé puis réinstallé fetchmail et la contrib smeserver-fetchmail, mais rien n'y fait. J'ai toujours le même soucis...

Je m'en remet donc aux experts qui passent par là.

Merci de votre aide.

[jdh]

Bonjour

(Je ne suis pas très connaisseur de SME).


Fetchmail est un outil bien adapté à une organisation boites externes/boites internes.

En mode daemon (le mode standard), tout les X secondes, fetchmail lance un process qui va récupérer les mails.

Par défaut X vaut 300 secondes soit 5 minutes.

Il NE FAUT PAS changer cette valeur. Et surtout ne pas la réduire ! C'est une TRES FAUSSE bonne idée.

Que risque-t-on ?
On risque un message tel "un autre fetchmail, au premier plan, est en exécution sur Y".
On risque de récupérer Z fois le même message.

En effet, la récupération est suivi de l'effacement des mails du serveur. Or si on a pas récupéré dans le temps imparti le mail et qu'un autre process fetchmail se lance, on obtient les 2 phénomènes cités.


Il faut noter que 300 secondes permet de récupérer un message en 2 minutes 30 en moyenne (statistiquement parlant). Ce n'est certes pas immédiat mais c'est presque immédiat ! Et cela suffit bien.


(Par exemple si on met X=60, une ADSL à 1M peut rapatrier environ 6Mo de mail par minute au maxi, dans la pratique 3M, on risque très vite les 2 phénomènes. Avec 5 minutes, il faudrait qu'une ou plusieurs boites ait reçu plus de 15 à 30M pour que cela se reproduise ...)

Action : remettre le daemon à 300 secondes.

[nidaime]

Merci jdh,

Je suis exactement dans ce cas de figure.
Par ton explication, tu viens de solutionner mon problème !

Merci encore

[jdh]

Pour juste un peu plus d'explication, et sans vouloir trop te "culpabiliser" (!), tu avais réglé à combien ?



En fait, pour toutes applications, on peut se poser la question des réglages par défaut. Celui qui conçoit l'application fait un choix, comme ceux qui créé une distribution (exemple SME). Sa (leur) réflexion est généralement saine et prudente.

Là, on pense modifier en disant 5 minutes c'est trop long. Alors que, d'une, c'est 2 minutes trente en moyenne statistique, et, de deux, c'est aussi lié à un mécanisme où le temps peut être trop court. D'où, mon effort pédagogique pour expliquer ce paramètre trop souvent touché ...

[sibsib]

Yop,

Juste quelques précisions :

Pour JDH : sur sme, fetchmail ne tourne pas en daemon, mais est lancé par cron.

La valeur par défaut dans la crontab est de 15 minutes. Il est possible (mais plustôt déconseillé !) de le passer à 5 minutes. Simplement, s'il y a plusieurs serveurs à poller et une ligne un peu lente ou chargée / un ou quelques gros messages / un des serveurs qui ne répond pas et on se trouve avec le fameux message "un autre fetchmail tourne en avant plan".

Sinon, j'ai eu une autre fausse bonne idée qui consistait à diminuer le timeout de polling de fetchmail, partant du principe que si un serveur ne répondait pas en 60 secondes, c'est qu'il ne répondrait pas.

Mezenfait, le paramètre de timeout est pour l'ensemble de la session de polling, donc 60 secondes face à un gros message ou un lien chargé, "c'est pas bon".

Donc, comme il va falloir que je sorte une nouvelle version mineure (pour un autre bug), je pense que je vais virer ce paramètre de timeout.

Voili,
Pascal

[jdh]

Merci Pascal (sibsib) de cette précision.

Ma connaissance est générale sur fetchmail. Sur Debian, par défaut, fetchmail est en daemon à 300 secondes ce qui fonctionne bien, en général.



(Une expérience vécue : pour une petite PME de 8 pers., j'ai installé un serveur unique en 2k3; j'ai ajouté VMware server et une VM Debian 4 Etch avec le système de mail "manuel" composé de Postfix+Dovecot+Mysql+fetchmail; or le système de temps tourne très mal : ni les VMtools ni ntp ne régule correctement le temps; j'ai donc fini par envoyer un +HUP tout les 5 minutes qui fonctionnent bien mieux que le daemon à 300 secondes; peut-être qu'un fetchmail en cron serait meilleur ...; peut-être qu'une SME serait meilleur ...; peut-être qu'un serveur dédié serait meilleur ...)

[nidaime]

En effet, sur SME, fetchmail est lancé par cron toutes les 15 minutes.

J'avais raccourcis ce délai à 5 minutes. Tout fonctionnait plutôt bien jusqu'à la réception de plusieurs emails contenant de grosses pièces jointe.
Avec une fréquence de réception trop courte et une connexion un peu lente, on se retrouve vite dans ce cas de figure.

sibsib: Je vais de ce pas aller vérifier le timeout

Merci pour toutes ces précisions

[sibsib]

Yop,

Dans la version actuelle, tu ne vois pas le timeout

J'ai ajouté cette option un peu vite, et elle n'apparait pas dans le panel.

La valeur par défaut est de 60 secondes ce qui est manifestement insuffisant.

J'ai tout de même prévu qu'on puisse être obligé de changer la valeur, mais c'est en ligne de commande :

Code: Tout sélectionner

# en tant que root :
config setprop FetchMails timeout 150
expand-template /etc/fetchmail
# ne pas tenir compte éventuellement d'un message d'erreur, qui arrive quand on installe la version de contribs.org ;-)

La modif est prise en compte dynamiquement (en fait par le expand-template).

Attention, un timeout de 150 secondes n'est envisageable qu'avec un poll remis à 15 minutes !

A+,
Pascal