Accéder au contenu.
Menu Sympa

fr - Re: priorites... et bug ?

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Olivier Salaun - CRU <adresse@cachée>
  • To: Dominique ROUSSEAU <adresse@cachée>
  • Cc: adresse@cachée
  • Subject: Re: priorites... et bug ?
  • Date: Thu, 23 Sep 1999 15:07:32 +0200

> Apres passage de sympa 2.2.7 a 2.3.1, je n'ai rien change au niveau des
> priorites (meme le fichier d'alias est le meme ;-), donc avec les
> valeurs par defaut, les messages du robot (priorite par defaut 1)
> devraient avoir priorite sur les messages des listes (defaut a 5), or il
> semble que Sympa continue a traiter la priorite sur les noms de fichiers
> dans le spool. Ceux du robot s'appelant sympa-* se retrouvent donc
> traite apres ceux qui se nommerainet par exemple abc-*...

Il s'agit d'un bug de la 2.3.x : lors du chargement de la config d'une
liste, sympa n'utilise pas le défaut de sa config (default_list_priority).
Corrigé dans la version de développement.

> De plus je trouve que l'ancien systeme de priorite etait plus souple car
> il permettait de configurer des priorites differentes pour les messages
> d'une liste et les bounces (auquel je mettait une priorite
> inferieure...)

Je vois ton problème. Nous ne passons pas les bounces à sympa, ils sont
interprétés par anabounce. On devrait pouvoir ajouter 3 nouveaux paramètres
à la config de sympa :

forward_request_priority : priorité des messages pour <nomliste>-request
forward_owner_priority : pour <nomliste>-owner, càd les bounces
forward_editor_priority : pour <nomliste>-editor, càd les modérateurs

Ca aurait plus de sens que d'appliquer la priorité de la liste.

Le déplacement des priorités dans les configs de liste va dans le
sens d'une simplification des alias, permettant d'automatiser l'installation
de listes, leur mise à jour.

> Sinon, j'ai remarque un petit probleme, qui malheureusement risque
> d'etre difficile a tracer...
> Parfois le demon s'arrete, sans message d'erreur dans les logs. A chaque
> fois ca se passe (observation uniquement) apres une operation SIG d'une
> personne non abonnee. Il met un message SIG ... refused because not on
> list
> Apparemment le message n'est pas le moins du monde en cause, car apre
> redemmarrage il le traite sans aucun probleme. D'ou le fait que ca va
> etre dur a tracer.

Notre sympa (2.3.2 sous Linux) traite des tonnes de refus de ce genre tous
les jours et il se porte comme un charme. Ce doit être platteforme dépendant
voire SGBD dépendant. As-tu testé sur une liste en mode database et file ?

> Je vais le faire tourner quelque temps avec un -d pour voir si raconte
> un peu plus de choses....

Tu peux utiliser le mode -D où chaque appel procédurale est tracé.


Olivier Salaün
Comité Réseaux des Universités





Archives gérées par MHonArc 2.6.19+.

Haut de le page