Accès au menu Préférences impossible, bug?

Salon des Bêta-Testeurs Core V4
1

Bonjour à tous,

image
image1584×383 58.7 KB

Depuis une mise à jour de routine du core je n’ai plus accès au menu Préférences, j’ai ce message en rouge

Trop de sessions, je ne peux pas lister : 395. Faire, pour les nettoyer : "sudo rm -rf /var/lib/php/sessions;sudo mkdir /var/lib/php/sessions;sudo chmod 777 /var/lib/php/sessions"

J’ai effectué la manip demandée mais le rep ‹ sessions › continu à se remplir a raison de # 1000 fichier / mn !

Apparemment tout le reste fonctionne, pour éviter une saturation disque j’ai mis en place un script de nettoyage avec un cron a la minute qui ne laisse que les fichiers de moins de 30 sec … Ca en laisse quand même qq centaines ! :frowning:

J’ai tenté aussi de désactiver les plugins ainsi que les le moteur de scénarios mais cela ne change rien

2

Bonjour.

Rien de suspect dans le moteur des tâches ?

3

Non, tout nickel

4

Bonjour,
Pas de trace de crash PHP dans le log http.error ?

5

non, tous les logs de Jeedom restent ‹ vierge ›

Il y a visiblement un process qui tourne en boucle qq part mais j’avoue ne pas savoir ou, pourtant pas faute d’avoir essayé de trouver !!!

Si par hasard, Loic passait dans le coin …

6

Bonjour
Les sessions sont créé par des connexions à jeedom ça peut venir d’appel api de plugin ou autre.

Pour le moment je reproduis pas.

7

Je continue mes investigations,

  1. le throw n’est pas vraiment utile puisque le code n’interprète QUE les cessions valides, les autres sont automatiquement filtrés

en modifiant le code de ‹ util.inc.php › (remplacement du throw par un message d’alerte) selon :

	if (count($sessions) > 100) {
//		throw new Exception(__('Trop de sessions, je ne peux pas lister :', __FILE__) . ' ' . count($sessions) . __('. Faire, pour les nettoyer :', __FILE__) . ' ' . '"sudo rm -rf ' . session_save_path() . ';sudo mkdir ' . session_save_path() . ';sudo chmod 777 ' . session_save_path() . '"');

	$message = (__('Trop de sessions, je ne peux pas lister :', __FILE__) . ' ' . count($sessions) . __('. Faire, pour les nettoyer :', __FILE__) . ' ' . '"sudo rm -rf ' . session_save_path() . ';sudo mkdir ' . session_save_path() . ';sudo chmod 777 ' . session_save_path() . '"');
	event::add('jeedom::alert', array("message" => $message, "level" => 'danger'));
	}
	
	foreach ($sessions as $session) {

L’accès aux Préférence utilisateurs est maintenu ainsi que le message avertissant qu’il y a un problème potentiel :

image
image1949×679 69.4 KB

  1. reste le problème de cette création de milliers de fichiers pour rien, ces fichiers ne contiennent d’ailleurs QUE l’IP d’appel (127.0.0.1) et RIEN d’autres ce qui me laisse penser que ce n’est pas un plugin qui les génère
8

Vu l’ip c’est un call interne donc un plugin.

9

Je pensais (a tord apparemment) que si un plugin il y aurait a minima de renseigné le user )

Mais bon, même en désactivant TOUS les plugins plus relance de Jeedom, le problème persiste :frowning:

10

Il faut supprimer les fichiers et voir si il reviennent

11

oui, j’ai été obligé de creer un script sur un cron de 1mn qui efface tous les fichiers de plus de 30sec de vie et malgré ça il s’en crée environ 700 toutes les mn :frowning:

12

Tu as un truc local qui se connecte en permanence à jeedom la. En gros si tu arrives sans cookies sur l’interface de jeedom php te crée une session et donc un fichier

13

j’ai désactivé tous les plugin => idem, j’ai aussi stoppé mosquito pour vérif., idem

Je ne vois plus quoi faire là :frowning:

Ce ne pourrait pas être une histoire cookies vérolés ? Un contrôle à faire de ce côté ?

14

Les cookies sont pas géré par jeedom c’est php directement.

Tu as pas un script qui tourne par hasard ?