[sympa-fr] Migration 5.2.4 vers 5.3.3 échoue comme dans " Migration 5.2.4 vers 5.3b4"

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

Bonjour,

J'avais signalé un pb de mise à jour de la 5.2.4 vers la 5.3b4 il y a
quelque temps (14 avril dernier). J'ai voulu profiter des derniers jours
de congés et de la stabilité de la 5.3 pour upgrader de 5.2.4 en 5.3.3.
Echec total.
Par rapport à la précédente migration (dont le CR est rappelé en fin de
courrier), j'ai bien observé l'erreur notée par Gauthier Catteau (
bind_col: column 154622216 is not a valid column (1..6)), qui a été
corrigée par l'application des maj CPAN sur les modules DBI et DBD::mysql
=> une remarque : DBI venait pourtant d'être upgradé par le make de
sympa... Manifestement, check_perl_modules.pl ne force pas la
réinstallation des modules comme le fait une install CPAN manuelle.

Sinon, j'observe toujours :
=> Des pbs d'encodage non résolus sur les tables utilisées par sympa :
List::get_user_db() 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,adresse@cachée,adresse@cachée'
" : Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and
(utf8_general_ci,COERCIBLE) for operation '='
=> des lock interminables : Upgrade::upgrade() Upgrade::upgrade(5.2.4,
5.3.3)
Upgrade::upgrade() Rebuilding config.bin files for ALL lists...it may
take a while...
Lock::_lock_file() Waiting for read lock on
/export/users/sympa/expl/listes.intranet.orleans.ird.fr/creer_liste/config.lock

Bref, le pb reste entier, le seuil 5.3 est toujours infranchissable, et
plus sympa avance en âge, plus le pb de lock devient critique (d'upgrade
en upgrade, wwsympa est considérablement ralenti, perd le contenu de ses
listes si les locks restent verrouillés trop longtemps). Enfin, je vois
maintenant apparaître ce message, "Aug 30 09:36:33
valinor.orleans.ird.fr sympa[15012]: Can't create new process in
safefork:" Je ne sais pas si c'est lié (les fs ont encore largement de
quoi s'étaler, et au niveau mémoire, top me signale de la mémoire réelle
comme du swap largement disponible).

Je reste à disposition pour plus de détails. Pour refaire un test, il
faudra que je monte une plateforme parallèle : je ne peux plus me
ridiculiser en annonçant des upgrade qui échouent immanquablement :-(



Luc VEILLON (DSI/SECU) a écrit :
> 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