LazyDbBackup MySQLi et O2switch avec PHP 7

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • LazyDbBackup MySQLi et O2switch avec PHP 7

    Bonjour à tous !

    Loïc m'ayant signalé un plantage de LazyDbBackup MySQLi chez O2switch en PHP 7, alors que les infos système du site montrent que MySQLi est bien activé, je me suis lancé dans des tests.
    C'est la première fois qu'un tel incident m'est signalé, et j'ai pas mal de sites chez divers hébergeurs qui sont utilisateurs de cette version.

    Donc chez O2switch en version 5.6 de PHP, aucun problème, la sauvegarde fonctionne.
    Que ce soit en PHP 7.0, 7.1 ou 7.2, page blanche dès qu'on clique sur un des boutons de validation ou annulation du plugin. Cette page est blanche car y est inséré du code avec une classe masquant le contenu (et que je n'ai pu voir qu'avec Opera).
    Sur mon site de test, ça enregistre bien une partie des données de la base, puis ça s'arrête sans affichage d'erreur. Le site utilisant Akeeba backup, ça semblait planter sur la partie "configuration" cryptée de la table ak_profiles. Après suppression de cette extension et de toutes les tables Akeeba, ça plante maintenant sur la première ligne de la table "assets".
    Les deux dernières lignes de la sauvegardes sont :
    /*!40000 ALTER TABLE `qxnbu_assets` DISABLE KEYS */;
    INSERT INTO `qxnbu_assets` (`id`,`parent_id`,`lft`,`rgt`,`level`,`name`,`titl e`,`rules`) VALUES
    L'analyse avec Jdump montre que le plantage se fait au niveau de la récupération du contenu et du type du champ "level" de cette table, dès la première ligne où il est à "0".
    Jdump est en effet capable de me donner le type de champ et la valeur des champs précédents, mais manifestement la lecture de ce champ renvoie des infos qui plantent tout, la page du site restant blanche car attendant que la sauvegarde soit officiellement terminée.
    La dernière information donnée par Jdump est que le dernier champ est "rgt", a pour valeur "139" et pour type "3". Rien sur le champ "level" qui suit.

    Impossible de récupérer quelque information que ce soit qui puisse expliquer ce plantage. La partie de code où se produit l'erreur débute à la ligne 270 du fichier mysql_db_backup.php
    Code PHP:
            while($row=mysqli_fetch_row($result)){
                if(
    $fp){
                    
    $line=' (';
                    for(
    $x=0;$x<$fields;$x++){
                        if(
    $x)$line.=',';
                        if (!isset(
    $row[$x])){
                            
    $line.='NULL';
                        }else{
                            if(
    mysqli_fetch_field_direct($result,$x)->type==3){
                                
    $line.=$row[$x];
                            }else{
                                
    $line.="'".mysqli_real_escape_string($this->link_id,$row[$x])."'"
                            }
                            
    //$line.=$row[$x];
                        
    }
                    } 
    La question est donc double : pourquoi ce plantage et pourquoi seulement sur toutes les versions 7 de PHP chez O2switch ?

    N'arrivant pas à intercepter d'erreur, je ne vois pas comment la gérer. Un paramétrage particulier de PHP pourrait-il être en cause, mais alors pourquoi une partie de la sauvegarde se fait-elle correctement ?

    Si quelqu'un a une idée de comment régler tout ça (en dehors de passer à la version PDO de LazyDbBackup qui, elle, fonctionne bien dans les mêmes conditions), je le remercie d'avance de ses conseils !
    Robert
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

  • #2
    Salut

    tu as quelle valeur pour memory limit?

    ++
    Wis

    Commentaire


    • #3
      Merci de ta réponse ! Elle est de 128 Mo, sachant que la base fait 5.4 Mo et que ça coince toujours sur la 5° table, donc après les tables de logs des actions sur un site que je suis seul à visiter et donc où il n'y a pas grand-chose dans ces tables-là (176 Ko selon phpMyAdmin)..

      Pour compléter, j'ai voulu tester une installation toute neuve d'une version 3.8.13 avec juste une page d'accueil en français. J'ai installé LazyDbBackup MySQLi et quand j'ai enregistré mes modifs (envoi du mail), la réponse a été :
      Service Unavailable


      The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

      Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.
      Ceci dit, il y a bien un enregistrement des tables jusqu'à là encore la création puis l'instruction d'insertion des valeurs de la table "#__categories", mais sans aucune donnée pour cette table... La sauvegarde non compressée s'arrête à 15 Ko
      Comme je l'ai dit plus haut, pas le moindre problème avec la version PDO qui me génère un fichier SQL (non compressé) de 256 Ko.
      Dernière édition par RobertG à 20/11/2018, 16h51
      "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

      Commentaire


      • #4
        Je cherche toujours quel paramètre dans les infos PHP pourrait provoquer ce blocage de lecture du contenu de la base, toujours au niveau des données et toujours sur la cinquième table, seulement en accès MySQLi aux données. Sur un autre site testé, où il y a eu plus d'extensions et d'accès, le plantage se fait pour un fichier SQL de 24 Ko au lieu de 15 comme dit dans mon précédent message. Il ne semble donc pas que ce soit une question de "volume", d'autant que le processus écrit en permanence ce qui est lu.
        Mystère, mystère...
        "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

        Commentaire


        • #5
          Bonjour,

          Je suis confronté à ce problème depuis déjà plusieurs mois, le retour à php 5.6 ayant résolu ce problème je ne l'ai pas signalé.

          Tout a commencé quand j'ai remarqué que je ne recevais plus la sauvegarde de la BDD. Ca n'a pas commencé au passage à PHP 7 mais plus tard.

          La réponse du support à mon alerte :

          Bonjour,

          J'ai tendance à penser que le problème peut venir des réglages PHP, à adapter en fonction des besoins ,cf : https://faq.o2switch.fr/hebergement-...ur-version-php

          Mais et à la vue de l'erreur, c'est typiquement une problématique de requête générée par le script lui même, et non d'hébergeur. Après, vous pouvez ne pas être confronté à un cas similaire chez un autre hébergeur, ou même chez nous pour un autre site : chaque problème est à prendre individuellement.
          Le message quand je veux sortir ou enregistrer le plugin :

          Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 1936025208 bytes) in /home/xxxxxxx/public_html/xxxxxxxx/plugins/system/lazydbbackup/lazydbbackup/mysql_db_backup.class.php on line 278
          Si vous trouvez une solution pour que je puisse revenir à php 7 ou supérieur.

          Merci de votre attention,

          B.


          Dernière édition par Le_villageois à 21/11/2018, 10h20

          Commentaire


          • #6
            Merci de l'info !
            La solution est de passer à la version PDO de LazyDbBackup qui n'a pas provoqué d'erreur jusqu'ici chez O2switch.
            Le message d'erreur m'étonne dans la mesure où comme je l'ai dit, le plugin lit et écrit immédiatement, ce qui ne devrait pas saturer la mémoire à ce point.

            PS : je viens de monter memory_limit à 1 Go et rien ne change...
            Dernière édition par RobertG à 21/11/2018, 10h41
            "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

            Commentaire


            • #7
              Salut

              Oups, dsl du mail tard, j'avais oublié que j'avais un thread en cours.

              Memory limit a 200M
              Post Max Size a 200M
              Upload Max Size a 200M

              J'ai rajouté un 0 devant les 20Mo d'origine et PHP 7.1
              Voici le message d'erreur avant la modif.
              Depuis, la mise a jour s'est faite correctement.
              Code PHP:
               PHP Fatal error:  Allowed memory size of 20971520 bytes exhausted (tried to allocate 9285632 bytes
              Je me demande pourquoi c'est extrement gourmand. C'est la premiere fois que je suis oblige de changer des valeurs en cours de fonctionnement de site.
              ( Site qui contient 10 pages, tres peu d'elements et/ou composant )

              ++
              Wis
              Dernière édition par Wismer à 23/11/2018, 10h37

              Commentaire


              • #8
                Merci ! Ce que je ne comprends pas non plus, c'est que le sql.gz soit tout petit si je suis en 5.6 et qu'il puisse planter (je n'ai pas eu le moindre message d'erreur, quoi que je fasse) en 7.0, 7.1 ou 7.2

                Je viens de refaire des tests en augmentant ces valeurs et finalement obtenu sous PHP 7.2 un dépassement de mémoire, tentant d'utiliser plus de 1,6 Go alors que le sql en PDO ne pèse que 1.31 Mo ! et 1.16 Mo en version MySQLi sous PHP 5.6
                Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 1667329920 bytes)
                "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                Commentaire


                • #9
                  J'utilise Akeeba pour faire ma sauvegarde et c'etait elle qui me faisait le plantage lors de la MAJ.

                  Est ce un pb Joomla ou Akeeba? ( je ne pense pas que ce soit un pb PHP )

                  Commentaire


                  • #10
                    Attention Wismer, là on parle de la version MySQLi de LazyDbBackup qui plante uniquement chez O2switch en PHP 7.x et pas en PHP 5.6, on ne parle pas d'Akeeba backup (avec qui je n'ai jamais rencontré ce problème).
                    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                    Commentaire


                    • #11
                      Je ne fais pas de confusion, mais mon pb qui s'apparente au tien , m'a ete causé par Akeeba et résolu par une augmentation mémoire.

                      C'etait une simple question, remarque.
                      Je vois un petit lien de parenté? et toi?
                      Pour mysql, je suis en 5.7

                      Je suis champion du monde pour faire des liens de parenté foireux.
                      Dernière édition par Wismer à 23/11/2018, 11h29

                      Commentaire


                      • #12
                        Non, aucune parenté dans la mesure où ça ne se produit pour LazyDbBackup que chez O2switch, qu'avec les versions 7, pas avec les versions 5, et seulement avec le mode d'accès aux données "MySQLi", pas avec le mode "PDO".
                        Et je n'ai pas exploré le code d'Akeeba pour savoir quelle méthode de lecture des bases cette extension utilise. En tout cas, pas d'erreur Akeeba sur mon site de test dont le jpa fait 25 Mo environ.
                        La seule similitude est la saturation de mémoire qui est invraisemblable en ce qui me concerne, 1,6 Go pour une base après écriture de 150 Ko de données selon phpMyAdmin, et seulement 7 Ko en texte SQL.
                        "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                        Commentaire


                        • #13
                          J'ai trouvé pour la lecture des champs une parade qui fonctionne chez O2switch, qu'il va me falloir tester et retester chez le même hébergeur et chez d'autres pour m'assurer qu'il n'y ait pas apparition d'autres erreurs ailleurs...
                          A suivre !
                          "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                          Commentaire


                          • #14
                            Bon, en fait, la tentative de remplacer "mysqli_fetch_field_direct" pour en obtenir le type de champ est en cause chez O2switch/MySQLi/PHP 7 mais la tentative de remplacement que j'avais précédemment faite avec réussite chez cet hébergeur déclenchait chez PHPNET des erreurs (Warning et Notice) sans problème apparent sur le contenu lui-même.
                            J'ai donc modifié mon code avec disparition de toutes les erreurs lors de mes premiers tests chez O2switch et PHPNET, en supprimant cette recherche du type de champ.
                            Restera à vérifier que ça ne posera pas de problèmes sous PHP 5 à ceux non encore passés à PHP 7.
                            "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                            Commentaire


                            • #15
                              En faisant quelques tests, je viens de m'apercevoir que ces versions comme les précédentes, en MySQLi ou PDO, posent un problème avec un compteur de visite qui enregistre sous forme binaire l'IP du visiteur. Quand j'essaie de vérifier le SQL généré, notepad++ plante, la sauvegarde n'ayant pas enregistré le contenu du champ binaire tel qu'il est réellement ! J'en reviens donc à la question de détermination du type de champ, sans saturer la mémoire, pour tenter d'éviter ce genre d'erreur...
                              Dernière édition par RobertG à 26/11/2018, 09h48
                              "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                              Commentaire

                              Annonce

                              Réduire
                              1 sur 2 < >

                              C'est [Réglé] et on n'en parle plus ?

                              A quoi ça sert ?
                              La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                              Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                              Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                              Comment ajouter la mention [Réglé] à votre discussion ?
                              1 - Aller sur votre discussion et éditer votre premier message :


                              2 - Cliquer sur la liste déroulante Préfixe.

                              3 - Choisir le préfixe [Réglé].


                              4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                              2 sur 2 < >

                              Assistance au forum - Outil de publication d'infos de votre site

                              Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                              Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                              Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                              UTILISER À VOS PROPRES RISQUES :
                              L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                              Problèmes connus :
                              FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                              Installation :

                              1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                              Archive zip : https://github.com/AFUJ/FPA/zipball/master

                              2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                              3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                              4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                              5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                              6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                              et remplacer www. votresite .com par votre nom de domaine


                              Exemples:
                              Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/
                              Pour executer le script: http://www..com/fpa-fr.php

                              Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/cms/
                              Pour executer le script: http://www..com/cms/fpa-fr.php

                              En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                              Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                              Voir plus
                              Voir moins
                              Travaille ...
                              X