Re: priorites... et bug ?

[Dominique ROUSSEAU <adresse@cachée>]

On Thu, Sep 23, 1999 at 03:07:32PM +0200, Olivier Salaun - CRU wrote:
> > 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.

hehe ;-)

> > 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.

Oui.
Eventuellement prevoir (pour etre complet) une valeur au niveau du
sympa.conf (donc portee golbale) et au niveau de chaque 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.

Je ne critiquais pas le principe, mais plutot la perte en souplesse.
Je dois meme dire que le fait d'avoir le nom de la liste dans les
fichiers de spool est un plus :)

> > 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

Oui, dans 9 cas sur 10 ca va passer, le 10eme badaboum.
Je relance et hop c'est reparti... jusk'au prochain ?!?

> voire SGBD dépendant. As-tu testé sur une liste en mode database et file ?

C'est sur une (des ?? tiens j'ai pas fait gaffe si c'etais tjs la
meme liste...), donc une liste en mode 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é.

Si le mode -d ne donne rien, j'essaierai ca, mais vu que ca genere bcp
d'info et que le probleme semble sporadique, je prefere le mettre dans
un mode moins bavard d'abord...

Dom

--
Dominique Rousseau <adresse@cachée>          
Neuronnexion - http://www.neuronnexion.com