Aller au contenu principal Aide Panneau de contrôle

 

support «   Soupçons de bogues «  

Les sessions ne sont jamais supprimées [Intégré]

Bernard Paques -- le 24 juil. 2011, depuis nearby-an-airport
YACS Leader

Il y a visiblement un problème dans yacs

PropriétaireBernard Paques
Avancement100%
WorkflowBesoin d'aide
StatutLa solution a été intégrée

j'ai été contrains de supprimer mon site yacs pour voir où se trouve le prob, Il faut noter que j'avais d'abords arrêter le serveur yacs en espèrent que les sessions allaient être nettoyées. Il faut noté que l'autologin est activé et le nombre de sessions n'a jamis cessé d'augmenter, alors que nous ne sommes pas un si grand nombre d'utilisateur à se connecter.

Je laisse le serveur en l'état pour l'instant, même si le site est inutilisable, j'espère vraiment pouvoir vous aider à trouver la source du problème.

j'ai juste fais via php la commande:

ls -trl /data/web/tmp/sessions|grep nutyx

Et vous pouvez voir le résultat ici:

http://download.tuxfamily.org/nutyx/sessions-1.jpg

http://download.tuxfamily.org/nutyx/sessions-2.jpg

http://download.tuxfamily.org/nutyx/sessions-3.jpg

http://download.tuxfamily.org/nutyx/sessions-4.jpg

Je ne crois pas que le problème vienne de tuxfamily.org

Bien à vous

Bernard Paques
le 13 août 2011
Bernard Paques est le nouveau propriétaire
La solution a été intégrée

Bernard Paques
le 13 août 2011

Le problème de base était lié à la taille des fichiers de session créés par yacs, ce problème a été traité à Il semble que mon cms yacs soit assez gourmant en espace disque et il est à présent réglé. Je change donc le statut de cette page pour indiquer la résolution du problème.


Bernard Paques
le 29 juil. 2011

J'en profite pour rappeler aux administrateurs de site yacs qu'ils disposent d'une commande pour faire afficher le résultat de phpinfo().

Depuis le Panneau de contrôle, choisir l'onglet Système, puis Environnement d'exécution, puis phpinfo(). Ceci affiche, au chapitre des données de session, l'état réel des paramètres session.gc_probability, etc.


Bernard Paques
le 29 juil. 2011

Pour répondre à la question concernant la configuration de yacs.fr, il s'agit en fait d'une installation complètement standard de PHP5 sous Linux Debian.

Le fichier /etc/php5/apache2/php.ini positionne session.gc_probability à 0, ce qui signifie que l'ancien mécanisme de purge, basé sur les probabilités, est désactivé.

Pourtant, le répertoire /var/lib/php5, qui contient les fichiers de session, est purgé régulièrement. Alors comment la purge est-elle effectuée ?

La réponse réside dans le fichier /etc/cron.d/php5, qui est activé deux fois par heure, et qui supprime les fichiers de session trop vieux.

Voici le contenu intégral de fichier, pour référence :

# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

Encore une fois, il s'agit d'une installation standard de PHP 5 sous Linux Debian, ni moi ni Christian ne sommes intervenus pour ajuster la configuration à ce niveau.

Avec ce système, les fichiers de session sont supprimés après 24 minutes d'inactivité.


Thierry Nuttens
le 29 juil. 2011

Je voulais dire Alexis bien-sûr, pas Bernard.

 

Bien à vous

Thierry

Thierry Nuttens
le 27 juil. 2011
La solution est disponible séparément
Thierry Nuttens
le 27 juil. 2011
Une solution est disponible

Thierry Nuttens
le 26 juil. 2011

@Xavier, merci pour la correction... tu as compris l'idée

@Bernard, non apparement cette variable est configuré après. Je pensais à la var globale SITE_ROOT_HASH

 

Bien à vous

 

Merci


Alexis Raimbault
le 26 juil. 2011

Thierry tu peux avoir le path de ton install dans la variable globale $context de yacs;

global $context;
$path = $context['path_to_root'].'tondossierlocal';

$context est initialisée dans global.php




Alexis Raimbault webmaster free-lance

Thierry Nuttens
le 26 juil. 2011

J'ai ajouté ces 2 lignes ds shared/global.php. Solution provisioire avant d'en trouver une définitive avec l'équipe yacs

 

session_save_path('/home/install/nutyx.org/nutyx.org-web/htdocs/sessions');
ini_set('session.gc_probability', 1);

Bien à vous

Thierry

Xavier Guerrin - le 26 juil. 2011

session_save_path('/home/install/nutyx.org/nutyx.org-web/htdocs/sessions');
ini_set('session.gc_probability', 1);

Hmm... et ça fonctionne encore l'ouverture de sessions ? Parce que ce chemin absolu n'existe pas (/home/install ?) et que même s'il apparaîssait dans l'arbo SSH, l'arbo des serveurs web est différente. Si tu veux vraiment déplacer tes sessions, ça a plus de chances de fonctionner avec un chemin relatif, ou caculé à partir de dirname(FILE)...


Thierry Nuttens
le 26 juil. 2011

Je crois que j'ai résolu le prob: A lire

http://www.php.net/manual/fr/function.session-save-path.php

Les hooks, c'est génial mais pas adapté pour ce problème, par contre, je m'en servirai pour autre choses.

 

A bientôt, pour de nouvelles aventures

 

Thierry

Xavier Guerrin
le 25 juil. 2011

Bonsoir,

Je confirme, TuxFamily nettoie le fameux dossier de session : tous les jours à 5h26, les fichiers, dossiers et liens symboliques ayant un ctime de plus de 1440 minutes, soit 24 heures, sont supprimés. Cela laisse donc dans le cas le plus pessimiste (à 5h25 du matin, le lendemain d'une purge qui n'aurait curieusement rien nettoyé pour Thierry ) 2 jours de sessions.

Le problème pour Thierry, c'est que cet intervalle de temps semble suffisant pour remplir son quota, et une purge toutes les 24 minutes semble une solution bien sévère. C'est pour cela que je me focalise sur la taille des sessions plus que sur leur création / purge, bien qu'il y ait peut-être des choses améliorables là-dessus aussi.

 


Alexis Raimbault
le 25 juil. 2011

Pas mal ton hook, mais il te faut un type 'include' plutôt que 'serve'

ensuite il te faudra aller sur l'url /control/scan.php et lancer l'analyse. Si tout se passe bien ton script sera listé parmi les prises d'extention

le 'tick' (évenement cyclique) se produit par cron.php. Si tu peux sur ton hébergement le lancer, il faut le dire à yacs dans le panneau de control. Sinon yacs se chargera d'injecter des tâches de fond lors des requêtes web. Le script ne se déclenche alors que lors qu'un visiteur passe.

Sinon Xavier a pourtant dit que les sessions étaient supprimées dans la journé ?




Alexis Raimbault webmaster free-lance

Thierry Nuttens
le 25 juil. 2011

Pour résoudre ce problème, je suis en train de mettre en place un hook qui serait exécuté en tache de fond, je me suis basé sur un hook de service existant rpc_echo_hooks.php. Mais je ne suis pas certain que mon service sera exécuté... Je mets ici le contenu de mon hook, quelqu'un pourra peut-être m'orienter.

// server hook
global $hooks;
$hooks[] = array(
'id' => 'tick',
'type' => 'serve',
'script' => 'services/sessions_hook.php',
'function' => 'Session::purge',
'label_en' => 'Sessions purge',
'label_fr' => 'Purge des sessions',
'description_en' => 'Recover the obsolets sessions',
'description_fr' => 'Suppression des sessions obsolets;',
'source' => 'http://www.nutyx.org/'
);

Class Session {
function purge() {
exec ('find /data/web/tmp/sessions -cmin +24 -group nut
yx -exec rm {} \;');
}
}

Merci pour votre aide

 

Thierry

 


Thierry Nuttens
le 25 juil. 2011

Extrait de php.ini

; NOTE: If you are using the subdirectory option for storing session files
;       (see session.save_path above), then garbage collection does *not*
;       happen automatically.  You will need to do your own garbage
;       collection through a shell script, cron entry, or some other method.
;       For example, the following script would is the equivalent of
;       setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
;          cd /path/to/sessions; find -cmin +24 | xargs rm

Tout devient beaucoup plus clair pour moi

Entre temps mon quota est à près de 100 Mb.

J'imagine que ce script est en place dans la plupart des cas.

 

Bien à vous

 

Thierry


Thierry Nuttens
le 24 juil. 2011

En exécutant le script de Xavier:

ds une page php (seul moyen pour moi de voir ce qui se passe)

<?php

$output = shell_exec('find /data/web/tmp/sessions -group 25778 -printf "%s\n" | perl -ne\'$t+=$_;END{printf("%.2fM for %d files\n",$t/1048576,
$.)}\'');
echo "<pre>$output</pre>";
?>

J'obtiens pour l'instant:

25.89M for 105 files

J'ai bien peur que demain mon quota sera déjà atteind...

Le prob n'est pas seulement la taille de ces fichiers (+ de 100kb) mais surtout que ces fichiers quelque soit leur taille ne s'effacent jamais.

Voili voilà


Concernant les visiteurs sur nutyx.org, j'en ai aucune idée

bonne chance

Thierry

 


Thierry Nuttens
le 24 juil. 2011

bonsoir Alexis,

Oui le site tourne, mais le prob n'est pas résolu. Le quota ne cesse de monté. Lorsque j'ai réinstallé yacs, il était logiquement à 29 Mb. Il est actuellement à 48 Mb.... et l'autologin n'est pas activé.

J'espère que l'on pourra rapidement trouver une solution

PS. Je serai curieux de voir le contenu du  dossier contenant les sessions sur le serveur qui héberge yacs.fr. En effet vous avez forcément le même problème

Bien à toi

 

Thierry

Alexis Raimbault - le 24 juil. 2011

Thierry Nuttens : J'ai pas accès à ces données sur yacs.fr, il faut demander à Bernard ou Christian.

toutefois il y a beaucoup de sites qui tournent sous yacs, et c'est la première fois que ce pb est soulevé. Néanmoins les quotas disques sont en moyenne plus élevés que 100Mo.

J'ai regardé sur un site qui reçoit une 20aine de visiteurs par jours.

J'ai 52 fichiers de sessions pour 12Mo, Le plus vieux des fichiers date de 18h00. ça tourne depuis 1 ans.

Il serait intéressant de savoir combien de visiteurs journalier tu reçois ?




Alexis Raimbault webmaster free-lance

Alexis Raimbault
le 24 juil. 2011

après une rapide revue je crois que cela joue seulement sur $_cookie c'est à dire le cookie du navigateur.

mais tu perds rien à essayer.

tu peux le désactiver à la main en éditant /parameters/users.include.php

mettre 'N' au paramètre 'users_with_permanent_authentication'




Alexis Raimbault webmaster free-lance
Thierry Nuttens - le 24 juil. 2011

Alexis Raimbault :

Ok je fais ça, on connait déjà l'origine du prob. Laughing

 

Si les dévelopeurs de yacs pouvaient se pencher sur la raison de "cacher" dans les fichier session_ l'info i18n ce serai pas mal.

 

Autre chose, également ajouter une possibilitée de purger les fichiers de session serait un plus à mon avis

Bien à toi

 

Thierry

Alexis Raimbault - le 24 juil. 2011

Thierry Nuttens : le site à l'air de tourner maintenant. Comment se comportent les sessions ?




Alexis Raimbault webmaster free-lance

Thierry Nuttens
le 24 juil. 2011

Oui je l'avais activé comme mentionné dans le message d'origine et j'avais l'intention de le déactiver car cela semble être l'origine du problème

A +

Thierry


Alexis Raimbault
le 24 juil. 2011

autre chose, tu n'aurais pas activé le mode Intranet ?

(panneau de control >> personnes >> onglet authentification >> dernier choix)




Alexis Raimbault webmaster free-lance

Alexis Raimbault
le 24 juil. 2011

tu n'as pas un moyen de mettre un traçeur sur les pages ? pour avoir une peu plus d'info sur les visites ?




Alexis Raimbault webmaster free-lance

Thierry Nuttens
le 24 juil. 2011

A voir la fréquence de création (toutes les minutes) ça ressemble plûtot à une attaque.

Qu'en pensez-vous

Thierry

Thierry Nuttens
le 24 juil. 2011
La page a été créée