[sympa-fr] Re: Re: Re: Migration 5.2.4 vers 5.3b4

["Luc VEILLON (DSI/SECU)" <adresse@cachée>]

Bonjour,

Quelques informations supplémentaires, après le patch et les précisions
apportées par Olivier Salaün :
=> mysql est en v4.1.7 sur solaris 9. Si la structure de la base n'a
donc pas été changée, l'upgrade 5.2.4 => 5.3.b4 provoque un changement
de codage en UTF-8 qui a un impact sur l'interclassement mysql, et donc
sur les requêtes soumises par sympa à sa base. Je n'ai pas d'explication
: la doc glanée sur internet offre la solution (modifier la variable
interclassement sur chaque table, via l'onglet opérations de
phpMyAdmin). Mais j'ai également trouvé :


      Les paramètres qui fonctionnent

    * Language : French (fr-utf-8)
    * Jeu de caractères pour MySQL: UTF-8 Unicode (utf8)
    * Interclassement pour la connection MySQL: utf8_general_ci
    * Interclassement pour la base : latin1_german_ci ou latin1_swedish_ci

Or, dans le cas de cette migration, c'était probablement dans ce cas de
figure qu'on était (la base restait en interclassement
latin1_swedish_ci, j'imagine que la connexion basculait en
utf8_general_ci). A vrai dire, la notion de locale/interclassement me
dépasse, mais c'était juste pour donner une piste à l'équipe programme
et conserver une trace de ce pb dans les archives de sympa-fr.

=> c'est un "make install" réappliqué depuis les sources 5.2.4 qui a
résolu le problème de locale sur lequel bloquait la version restaurée de
sympa. Après vérification, j'ai constaté que le répertoire "locale" de
sympa n'était pas sauvegardé avec le reste... Ceci explique sans doute
que le pb n'ait jamais été remonté au CRU, tout le monde sauvegardant
correctement sympa ;-)

=> je ferai une tentative de migration en utilisant le patch de la 5.3b
un peu plus tard. Je dois réobtenir un créneau d'intervention pour ce
serveur en prod.

Cordialement

adresse@cachée a écrit :
> Bonjour,
>
> Voici un point de situation sur ma tentative de migration de 5.2.4 en
> 5.3.b4
>
> * sympa.pl --upgrade a parcouru mes 81 listes réparties sur 4 robots
> (standard + 3 virtuels) en  plus de 18 heures !! Pour chaque liste, il
> a attendu longuement l'accès au fichier include_admin_user.locsk :
> Apr 14 00:06:06 valinor.orleans.ird.fr sympa[21268]: Waiting for read
> lock on /e
> xport/users/sympa/expl/listes.ird.fr/ird-tous-ext/include_admin_user.lock
> Apr 14 00:06:06 valinor.orleans.ird.fr last message repeated 4 times
> Apr 14 00:11:06 valinor.orleans.ird.fr sympa[21268]: Failed locking
> /export/user
> s/sympa/expl/listes.ird.fr/ird-tous-ext/include_admin_user.lock: I/O
> error
>
> * une fois terminé le parcours de toutes les listes, il a recommencé à
> 0, pour reconstruire la table admin_table, et s'est heurté aux mêmes
> blocages :
> Apr 14 09:42:07 valinor.orleans.ird.fr sympa[21268]: Rebuilding the
> admin_table.
> ..
> Apr 14 09:42:07 valinor.orleans.ird.fr sympa[21268]: Waiting for read
> lock on /e
> xport/users/sympa/expl/listes.intranet.orleans.ird.fr/creer_liste/include_admin_
>
> user.lock
>
> * ne souhaitant pas repartir pour un test (sans doute inutile) de 18h,
> j'ai arrêté le processus. En cherchant un peu au hasard, je suis tombé
> sur le début du fichier Lock.pm :
> my $default_timeout = 60 * 20; ## After this period a lock can be stolen
> que j'ai réduit en :
> my $default_timeout = 6 * 2; ## After this period a lock can be stolen
> pour me laisser un peu plus de chance d'aboutir rapidement.
>
> * la relance de l'upgrade a donné les mêmes blocages et attente de
> fichiers *.lock, tout juste un peu accélérés par rapport à l'essai
> précédent.
>
> * j'ai décidé d'arrêter les frais, et je suis reparti sur la
> sauvegarde complète de sympa 5.2.4, tout en conservant la base mysql
> dans son état.
> * sympa.pl a alors signalé des erreurs mysql du type :
>  Illegal mix of collations (utf8_general_ci,IMPLICIT) and
> (latin1_swedish_ci,COERCIBLE) for operation 'locate'
> * j'ai remis le codage latin1_swedish_ci sur toutes les tables et sur
> chaque paramètre, ainsi que comme défaut de la base sympa.
> * sympa.pl a alors accepté de démarrer, il sert correctement les
> requêtes qui lui sont envoyées par mail MAIS wwsympa ne fonctionne plus.
>
> d'une part il reste bloqué des quart d'heures entiers sur :
> Apr 14 12:30:13 valinor.orleans.ird.fr wwsympa[15798]: WWSympa started
> Apr 14 12:30:13 valinor.orleans.ird.fr wwsympa[15798]: Waiting for
> read lock on
> /export/users/sympa/expl/listes.intranet.orleans.ird.fr/creer_liste/include_admi
>
> n_user.lock
>
> (et l'arrêt complet de sympa, wwsympa, destruction des locks puis
> redémarrage ne change rien)
>
> d'autre part, il signale maintenant dans ses propres logs apache :
> [Sat Apr 14 11:48:52 2007] [error] [client 90.19.72.56] FastCGI:
> incomplete head
> ers (0 bytes) received from server "/export/users/sympa/bin/wwsympa.fcgi"
> [Sat Apr 14 12:27:36 2007] [error] [client 90.19.72.56] FastCGI:
> server "/export
> /users/sympa/bin/wwsympa.fcgi" stderr: Unknown encoding '' at
> /dev/fd/3 line 108
> 2
> [Sat Apr 14 12:27:36 2007] [error] [client 90.19.72.56] FastCGI:
> server "/export
> /users/sympa/bin/wwsympa.fcgi" stderr: Unknown encoding '' at
> /dev/fd/3 line 108
> 2
>
> Le "Unknown encoding ''" est nouveau, et n'apparaissait pas avant la
> tentative de migration. Une scorie du changement de base j'imagine...
>
> Nous allons tenter une restauration de la base lundi matin. Mais il y
> a peut être plus simple.
>
> Si vous avez des idées ?
>
> merci,
>
>
>
>
>
> "Luc VEILLON (DSI/SECU)" <adresse@cachée> a écrit :
>
>> Luc VEILLON (DSI/SECU) a écrit :
>>> Luc VEILLON (DSI/SECU) a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> Je migre en ce moment même mon moteur de listes de 5.2.4 en 5.3b4.
>>>> Tout se passe apparemment bien, si ce n'est que ja commande d'upgrade
>>>> perd un temps fou à surmonter ses propres config.lock
>>>>
>>>>
>>> => Il faut lancer l'upgrade en tant qu'utilisateur sympa (c'est sans
>>> doute évident, mais on peut oublier...)
>>> Par contre, je vois maintenant un tas d'erreur du type :
>>> Unable to execute SQL statement "SELECT email_user AS email, gecos_user
>>> AS gecos, password_user AS password, cookie_delay_user AS cookie_delay,
>>> lang_user AS lang , attributes_user AS attributes FROM user_table WHERE
>>> email_user = 'adresse@cachée,adresse@cachée' " :
>>> Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and
>>> (utf8_general_ci,COERCIBLE) for operation '='
>>>
>> C'est une migration qui se mérite...
>> Solution : passer par l'interface PhpMyAdmin et modifier a la main la
>> définition de toutes les tables pour les passer de latin1_swedish_ci en
>> utf8_general_ci.
>> Comme je suis un bourrin, j'ai commencé par changer chaque paramètre de
>> chaque table, mais en fait, le menu "opérations" de phpmyadmin permet de
>> le faire globalement pour chaque table.
>>
>> C'est à suivre, car maintenant, le config.lock et l'update sql passent,
>> mais je retrouve les time-out à l'étape de l'include_admin :
>> Waiting for read lock on
>> /export/users/sympa/expl/listes.intranet.orleans.ird.fr/creer_liste/include_admin_user.lock
>>
>> Waiting for read lock on
>> /export/users/sympa/expl/listes.intranet.orleans.ird.fr/creer_liste/include_admin_user.lock
>>
>>
>>> Le listmaster reçoit ensuite ce message :
>>>
>>> Aucun propri�taire d�fini pour la liste tous-idf
>>> Le statut de la liste a �t� positionn� � error_config.
>>> Consultez les logs de Sympa pour plus de pr�cisions.
>>>
>>> ... pour chaque liste
>>>
>>> Des idées ??
>>>
>>>
>>>> Waiting for read lock on
>>>> /export/users/sympa/expl/listes.ird.fr/acces_diff_ird/config.lock
>>>> Waiting for read lock on
>>>> /export/users/sympa/expl/listes.ird.fr/acces_diff_ird/config.lock
>>>> Waiting for read lock on
>>>> /export/users/sympa/expl/listes.ird.fr/acces_diff_ird/config.lock
>>>> Waiting for read lock on
>>>> /export/users/sympa/expl/listes.ird.fr/acces_diff_ird/config.lock
>>>> Waiting for read lock on
>>>> /export/users/sympa/expl/listes.ird.fr/acces_diff_ird/config.lock
>>>> (...)
>>>> Failed locking
>>>> /export/users/sympa/expl/listes.ird.fr/acces_diff_ird/config.lock:
>>>>
>>>> et je vous épargne la suite (j'en suis à la troisième liste au bout de
>>>> 30 minutes environ et j'en ai encore une cinquantaine à faire :-(
>>>>
>>>> J'ai vérifié : tous les process sympa et apache étaient arrêtés au
>>>> moment de la migration, et je n'avais aucun config.lock. Apparemment :
>>>> * l'upgrade crée un fichier config.lock,
>>>> * il se met ensuite à dormir
>>>> </export/users/sympa/expl>valinor<root>: ps -aef | grep sympa
>>>>    sympa 21866 14207  0 11:52:32 pts/4    0:06 /usr/local/bin/perl
>>>> /export/users/sympa/bin/sympa.pl --upgrade
>>>>    sympa 21875 21866  0                   0:00 <defunct>
>>>> </export/users/sympa/expl>valinor<root>: truss -p 21866
>>>> nanosleep(0xFFBFF810, 0xFFBFF808) (sleeping...)
>>>> * il défuncte :
>>>> </export/users/sympa/expl>valinor<root>: ps -aef | grep 21866
>>>>    sympa 21866 14207  0 11:52:32 pts/4    0:06 /usr/local/bin/perl
>>>> /export/users/sympa/bin/sympa.pl --upgrade
>>>>    sympa 21875 21866  0                   0:00 <defunct>
>>>>     root 21870 21866  0                   0:00 <defunct>
>>>> * il laisse comme trace de sa vie fugace sur cette terre un
>>>> cofnig.lock :
>>>> </export/users/sympa/expl>valinor<root>: find . -name config.lock
>>>> ./listes.intranet.orleans.ird.fr/essai_intranet/config.lock
>>>> ./listes.ird.fr/acces_diff_ird/config.lock
>>>> ./listes.ird.fr/agents-tous/config.lock
>>>> * une banale règle de trois me montre qu'il va parasiter les
>>>> ressources
>>>> de mon serveur jusqu'à 16h => ca me laisse le temps de vous écrire et
>>>> d'espérer une réponse rassurante !
>>>>
>>>> Merci pour tout aide
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> -- 
>>      Luc VEILLON              | IRD/Délégation aux systèmes
>> d'information/
>>      tel.:+33(0)2 38 49 95 95 | RSSI - Pôle APPUI RECHERCHE/coord.
>> technique
>>      Fax :+33(0)2 38 49 95 76 | 5, rue du carbone
>>      adresse@cachée   | 45072 ORLEANS CEDEX 2
>>      gpg : 0xDC6FF566           | AC signature :
>> http://igc.cru.fr/ac-racine/
>>
>>
>>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>


-- 
     Luc VEILLON              | IRD/Délégation aux systèmes d'information/
     tel.:+33(0)2 38 49 95 95 | RSSI - Pôle APPUI RECHERCHE/coord. technique
     Fax :+33(0)2 38 49 95 76 | 5, rue du carbone                       
     adresse@cachée   | 45072 ORLEANS CEDEX 2
     gpg : 0xDC6FF566         | AC signature : http://igc.cru.fr/ac-racine/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature