[RÉGLÉ] Petit souci de session

[Peggy]

Bonjour, j'ai un message d'erreur en front office ET en back office. Impossible d'accéder à l'admin joomla.

Error: Failed to start application: Could not connect to MySQL server. Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in /var/www/vhosts/FilerWeb07/sarl-mahot.fr/httpdocs/libraries/joomla/session/handler/native.php on line 194

C'est sur ce site : http://www.sarl-mahot.com/
Joomla 3.8.7
php 7.0.18
hébergeur mutualisé chez Hosteur.com

Dans le fichier native.php, à la ligne 194 j'ai : session_write_close();
Dans le fichier configuration.php il n'y a pas deligne avec session.save_path
J'ai vidé le dossier logs mais cela n'a rien changé.
J'ai accès au FTP via Filezilla

Auriez-vous une piste ?
Merci
Peggy

[RobertG]

C'est ta table "sessions" dans la base qui doit être saturée.
Ouvre ton fichier configuration et cherche :

public $session_handler = 'database';

pour remplacer par

public $session_handler = 'none';

Tu peux aussi vider la table sessions dans ta base.

[ZerooCool]

A ma première tentative de connexion, j'ai vu l'erreur en front-end. Je me reconnecte une seconde fois puis je vois le site.
Je suppose que tu viens d'intervenir et de régler le problème.

[Peggy]

Si tu vois le site c'est que ce doit être un cache ou un historique. Le site est toujours HS. Je suis encore en cours d'intervention sur la base de données. Comme je n'arrive pas à faire ce que je veux sur la base, j'ai contacté l'hébergeur, mais leurs réponses sont très longues à venir (24h par question en moyenne). Exemple : je ne peux pas supprimer la base pour réinjecter une sauvegarde. J'ai des messages d'erreur qui m’empêche de supprimer ou vider la base.

[jfque]

Le message d'erreur indique que la table #__session n'existe pas. Avez-vous essayé de la recréer ?

[Peggy]

Oui. Dans l'ordre concernant la base de données :
- j'ai vidé la table session, mais elle a disparu. Je crains avoir cliqué sur "supprimer" à la place de "vider".
- Du coup j'ai tenté d'importer uniquement la table session : error.
- Puis j'ai tenté de la réécrire à la main : error.
- Puis j'ai tenté de vider la base complète (error) pour la réimporter entièrement : error.

voici le message de PHPMyAdmin :

1 erreurs trouvées lors de l'analyse.
Expression manquante. (near "ON" at position 25)
Requête SQL : Éditer Éditer
SET FOREIGN_KEY_CHECKS = ON;
MySQL a répondu : Documentation
#2006 - MySQL server has gone away


De ce fait, je me demande si le serveur ne serait pas " trop protégé" en écriture. J'ai demandé à l'hébergeur Hosteur de réimporter une base de données, mais ils sont en congés visiblement.

-----------------------

Concernant le fichier configuration j'ai remplacé
public $session_handler = 'database';
par
public $session_handler = 'none';

-----------------------
voilà où j'en suis.

[RobertG]

Si tu as des sauvegardes récentes de ta base, récupère simplement la partie "CREATE TABLE" concernant la table "sessions" et utilise l'onglet SQL de phpMyAdmin pour recréer cette table.

Et plutôt que nous dire "error", donne-nous le message exact dans chaque cas.

[Peggy]

J'ai tenté de recréer la table avec l'onglet SQL de phpMyAdmin. Voici le résultat :
Erreur

Requête SQL :


CREATE TABLE `ihxe6_session` (`session_id` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '', `client_id` tinyint(3) unsigned DEFAULT NULL, `guest` tinyint(4) unsigned DEFAULT '1', `time` varchar(14) COLLATE utf8mb4_unicode_ci DEFAULT '', `data` mediumtext COLLATE utf8mb4_unicode_ci, `userid` int(11) DEFAULT '0', `username` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT '')


MySQL a répondu :
#1146 - La table 'BDDmahot2017.ihxe6_session' n'existe pas

[RobertG]

Il est très étrange que la réponse à un "CREATE TABLE" soit

#1146 - La table 'BDDmahot2017.ihxe6_session' n'existe pas

Voilà ce que donne le code de création de cette table sur un de mes sites :

CREATE TABLE `u0as1_session` (
  `session_id` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `client_id` tinyint(3) UNSIGNED DEFAULT NULL,
  `guest` tinyint(4) UNSIGNED DEFAULT '1',
  `time` varchar(14) COLLATE utf8mb4_unicode_ci DEFAULT '',
  `data` longtext COLLATE utf8mb4_unicode_ci,
  `userid` int(11) DEFAULT '0',
  `username` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Ton code, s'il a bien été collé, ne comporte pas le point-virgule de fin.
Ensuite, bien que tu sois en version 3.8.7, "data" n'a pas le même type que chez moi.

[Peggy]

oui c'est étrange.

J'ai retenté de créer la table avec l'onglet SQL de phpMyAdmin
--------------------------------------------
CREATE TABLE `ihxe6_session` (
`session_id` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`client_id` tinyint(3) unsigned DEFAULT NULL,
`guest` tinyint(4) unsigned DEFAULT '1',
`time` varchar(14) COLLATE utf8mb4_unicode_ci DEFAULT '',
`data` mediumtext COLLATE utf8mb4_unicode_ci,
`userid` int(11) DEFAULT '0',
`username` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT '',

PRIMARY KEY (`session_id`),
KEY `userid` (`userid`),
KEY `time` (`time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
DROP TABLE IF EXISTS `ihxe6_tags`;



Le message d'erreur est le même : #1146 - La table 'BDDmahot2017.ihxe6_session' n'existe pas

--------------------------------------------

J'ai aussi retenté de supprimer toute la base et j'ai ce message :

1 erreurs trouvées lors de l'analyse.

Expression manquante. (near "ON" at position 25)
Requête SQL :

SET FOREIGN_KEY_CHECKS = ON;

MySQL a répondu :

#2006 - MySQL server has gone away
---------------------------------------------

Je ne peux donc même pas supprimer la base de données. Est-ce possible que l'hébergeur contraigne ou protège la base de données ?

[RobertG]

Chez certains hébergeurs, une base doit être vide avant de pouvoir être supprimée.
Mais avec phpMyAdmin, on doit pouvoir ajouter, supprimer, compléter... une base comme a droit de le faire un script PHP. Il est donc tout à fait illogique que tu aies de telles erreurs lors d'une création de table. En mutualisé, une création ou suppression de base n'est autorisée qu'au serveur, pas à l'utilisateur, mais toutes les opérations basiques sont autorisées à cet utilisateur.

As-tu la possibilité de tester la restauration de la sauvegarde de ta base sur un autre serveur, local par exemple ?

[Peggy]

Les choses avancent. Une sauvegarde de la base de données a pu être importée. Le site est reparti en frontend et backend.
J'ai pu faire les mises à jour d'extensions.
-----------------------------------------
J'ai un NOUVEAU BUG en backend via joomla/extensions/base de données

2 problèmes de base de données trouvés

La version (3.8.4-2018-01-16) du schéma de la base de données ne correspond pas à la version (3.8.6-2018-02-14) du CMS.
La version (3.8.5) de mise à jour de la base de données ne correspond pas à la version (3.8.7) du CMS.

onglet "Autres informations"

Version du schéma de la base de données (dans #__schemas): 3.8.4-2018-01-16
Version de la mise à jour (dans #__extensions): 3.8.5.
Pilote de la base de données: mysqli
150 modifications de base de données vérifiés.
185 valeurs de modifications de la base de données ne changent pas la structure des tables et ont été ignorées.
-----------------------------------------

ça vous parle ?
merci de votre aide.
Peggy

[RobertG]

Clique sur le bouton "Correction", dans cette page

[Peggy]

La correction s'est bien passée. Tout est OK. Je vous remercie de votre aide.
Je sauvegarde immédiatement le site.
et je ferme la discussion. C'est réglé.

[claudiusIII]

Bonsoir Peggy et RobertG,

Serveur Debian 8.11
Joomla 3.9
PHP5.6

et

Serveur Debian 9.5
Joomla 3.9
PHP7.0

Message d'erreur sous page blanche marqué "error" :

Error: Failed to start application: Could not connect to MySQL server.
Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions) in /var/www/vma/libraries/joomla/session/handler/native.php on line 194

Je me permets de vous envoyer ce post car j'ai actuellement le même souci que Peggy. En effet Joomla 3.9 fonctionne tout à fait correctement sous mon serveur web debian 8.5 et PHP 5.6 mais provoque ce type d'erreur sous Debian 9.5 et PHP 7.0. J'ai suivi les manips données à Peggy mais rien n'y fait. J'ai l'impression que le problème vient de PHP 7.0 ou peut-être d'un paramètre du php.ini. Apparemment Joomla ne trouve pas la direction de la base de donnée MYSQL 5.6

Par contre les sites en html fonctionnent bien.

Et je ne suis pas blond

Cordialement

Claude