Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

hr · Le 22/04/2015, à 12:59

Bonjour tout le monde.
J’ai un petit problème pas très grave mais qui commence à un peu m’user les nerfs…
Lorsque je quitte une session, quel que soit le compte, j’ai un écran vide pendant exactement 1 mn 30 avant de pouvoir retourner dans l’écran de connexion de lightdm.

Ça ressemble à une appli, un service ou je ne sais quoi qui tourne en arrière plan et qui refuse de se fermer puis qui, après un time out, est tué par le système. Mais quoi ?
J’ai plusieurs choses qui tournent, Apache, Syncthing, ssh, netatalk mais tout ça n’est pas lié à la session et, bien entendu, j’ai fait des essais en les arrêtant l’un après l’autre, en vain. Je suis allé jusqu’à les désinstaller tous sans plus de résultat.

J’imagine aussi qu’il pourrait y avoir un problème de droits sur quelque chose qui doit s’exécuter pour fermer la session et qui est altéré. Je sèche complètement.
Réinstaller le système, c’est une journée complète de boulot, pas vraiment envie…
En attendant, pour aller plus vite, je passe en console et lance un restart lightdm mais c’est un peu lourd.

Autant vous dire que si quelqu’un a une idée, bonne ou même mauvaise, j’en serais ravi !

J’ai évidemment cherché sur le forum mais n’ai rien trouvé d’approchant.
Ubuntu 14.04 en 64 bits

Dernière modification par hr (Le 12/04/2016, à 10:58)

Rufus T. Firefly · Le 22/04/2015, à 13:14

Salut,

Dans les idées probablement mauvaises, vérifie la swap.

sudo blkid | grep swap
cat /etc/fstab | grep swap

Normalement tu devrais avoir le même uuid...

hr · Le 22/04/2015, à 18:39

Merci pour l’idée !
Le problème n’était pas de ce côté-là mais il était bon de vérifier.
De plus ça me rappelle la commande blkid que j’avais oubliée ce qui faisait que je me compliquais inutilement la vie pour trouver les id des partitions.
Je cherche aussi du côté des applications lancées à l’ouverture de session mais je ne trouve rien de louche là non plus.

Rufus T. Firefly · Le 22/04/2015, à 19:26

N'as-tu pas remarqué une certaine lenteur au démarrage, aussi ?
Essaye ça :

gksudo gedit /etc/default/grub

Remplace "quiet splash" par "" dans la ligne GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
Enregistre, puis

sudo update-grub

Redémarre et observe si ça ne bloque pas quelque part pendant... 1'30
Si oui, c'est probablement lié à fsck, et peut-être à l'état du disque.

Dernière modification par Rufus T. Firefly (Le 22/04/2015, à 19:33)

hr · Le 22/04/2015, à 19:31

Non, pas du tout. D’ailleurs tout est normal par ailleurs.
J’essaye ta manœuvre mais si ça coinçait 1 Mn 30, je m’en apercevrais, c’est un PC un peu vieux mais le démarrage est rapide.
J’essaye tout de même dans quelques minutes, dès qu’il a fini ce qu’il est en train de faire.
-------------------------
Voilà, j’ai essayé et il n’y a rien d’anormal, le démarrage est fluide et rapide d’un bout à l’autre. Bigre, ce pépin m’embête, décidément !
Je n’ai pas procédé exactement comme tu l’as dit mais ça revient au même : j’ai édité la ligne dans grub en supprimant le quiet splash et j’ai bien eu le défilement de tous les messages.

Dernière modification par hr (Le 22/04/2015, à 20:49)

hr · Le 21/05/2015, à 00:58

Devenant un rien impatient avec ce problème idiot, j’ai réinstallé le système sur mon disque de secours. J’ai même installé 14.04.2 histoire de ne pas avoir le même noyau.

Que croyez-vous qu’il advint ?
Il s’est passé rien de rien…
Passé l’pc au moulin
Rest’plus qu’à m’pendre demain !

Non, quand même pas mais ça me laisse plus perplexe encore. S’il s’agit de quelque chose qui ne tient pas au système tel qu’il est installé, ça peut tenir à quoi ? Au bios ?????
Non mais là, où chercher ? Il doit bien y avoir quelque chose que je n’ai pas essayé, mais quoi, sabre de bois !?

J5012 · Le 21/05/2015, à 01:13

verifie les applications gerées par lightdm (ceux dispo des son chargement, et non seulement apres l'ouverture de session, utilise xhoxt pour ca)

moko138 · Le 21/05/2015, à 03:58

Une autre astuce :
passer en console puis éteindre par

sudo shutdown -h now

ou

sudo shutdown -r 0

ou

sudo reboot

Tu devrais voir quel processus prend ce temps excessif.

hr · Le 21/05/2015, à 09:06

Merci à tous les deux de vous intéresser à mon exaspérant problème !

@J5012
xhoxt je ne sais pas du tout ce que c’est et je n’ai rien trouvé.

@moko138
Comme il m’arrive de travailler en console, j’ai fait ça un grand nombre de fois depuis que j’ai ce problème et il n’y a rien de notable. L’arrêt est très rapide tout comme le démarrage.
Si je redémarre ou que j’arrête la machine, que ce soit depuis la console ou depuis un compte, l’arrêt et le redémarrage sont normaux, c’est à dire très rapides.

Le problème n’apparaît qu’en fermant la session du compte, par exemple pour relancer la session ou passer sur un autre compte. C’est le seul cas où le problème apparaît et il y a cette minute et demie exactement durant laquelle l’écran s’est vidé de ses fenêtres comme si la session se fermait normalement sauf que plus rien ne se passe.

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

Une chose intéressante, peut-être :
Pendant les 1,5 mn je passe en console et je fais un ps -U moi -al et je vois que tous les processus de la session sont toujours là, tous sans activité mais ils ne sont pas fermés. Tout se passe comme si la fermeture de session fermait les fenêtres mais pas les processus qui finissent par être tués au bout du time out.

Dernière modification par hr (Le 21/05/2015, à 09:37)

Rufus T. Firefly · Le 21/05/2015, à 11:56

Encore une idée, peut-être idiote !
Dans /etc/lightdm/lightdm.conf, il y a probablement (c'est le cas chez Debian) ces lignes :

...
# session-cleanup-script = Script to run when quitting a user session (runs as root)
...
# autologin-user-timeout = Number of seconds to wait before loading default user
...

Elles sont commentées chez Debian, mais il y a peut-être quelque chose chez ubuntu... En particulier un script " to run when quitting a user session"...

Je n'y crois pas beaucoup, mais sait-on jamais, et c'est vite vu.

hr · Le 21/05/2015, à 12:11

Merci pour l’idée mais non, ce n’est pas pareil et ce fichier était déjà comme il est avant l’apparition du problème :

[SeatDefaults]
autologin-guest=false
autologin-user= < mon compte >
autologin-user-timeout=30
autologin-session=lightdm-autologin
allow-guest=true
greeter-show-manual-login=true
user-session=unity

Je serai sans machine en Ubuntu jusqu’à la fin de la semaine. Je reprendrai le fil dimanche.
En attendant, merci pour ceux qui se sont intéressés à mon pépin.

Rufus T. Firefly · Le 21/05/2015, à 17:27

Encore une idée idiote... Mais on finira par trouver...

https://forum.ubuntu-fr.org/viewtopic.php?id=1842021

ça a pour conséquences de bloquer l'arret de la machine pendant 5 mn avant l'extinction de celle-ci

C'est peut-être une piste, d'autant plus que systemd est une invention assez récente et qu'il y a peut-être encore des petites choses pas claires qui traînent...

moko138 · Le 21/05/2015, à 18:18

Et si on s'intéressait aux logs ?

hr · Le 22/05/2015, à 09:14

@Rufus T. Firefly
Merci, toute idée est à regarder dans l’état de perplexité dans lequel je suis… Mais la machine concernée par mon problème est en 14.04 donc pas de systemd.

@moko138
Je suis en déplacement jusqu’à dimanche et je poursuivrai à ce moment-là. J’avais déjà regardé les logs et ce que j’y ai vu n’a pas été très parlant. Mais tu as raison, il devrait fatalement y avoir quelque chose si une tempo claque et finit par fermer la session de force en tuant la tâche qui coince. Je regarderai tout ça de plus près à mon retour.

hr · Le 24/05/2015, à 18:37

Voilà les logs au moment où je tente de fermer la session à 18h 25mn 00s
jusqu’à ce qu’elle se ferme effectivement, 1 mn 30 plus tard, soit à 18h 26mn 30s
Avant et après, calme plat et rien à signaler.

May 24 18:25:01 AsusLinux colord: device removed: xrandr-H224W-H224WE840075
May 24 18:25:01 AsusLinux colord: Profile removed: icc-987be6c27c09cf736bab2a1357e5009d
May 24 18:25:01 AsusLinux colord: Profile removed: icc-d002a348bb4f91d5dfbd95a66a8e00b5
May 24 18:25:01 AsusLinux colord: Profile removed: icc-f8a1a4269bfa519420117fce0143037b
May 24 18:25:01 AsusLinux colord: Profile removed: icc-c6a16d1b80cd690ce8f19d5ff9e8c5ca
May 24 18:25:01 AsusLinux colord: Profile removed: icc-dcc4bb6480e3130777216f557e101be1
May 24 18:25:01 AsusLinux colord: Profile removed: icc-68f09c6b6b8ab1a1c1f9d62e5f798b19
May 24 18:25:01 AsusLinux colord: Profile removed: icc-929fdf61afadd0d5b0d60da1f165f358
May 24 18:25:01 AsusLinux dbus[830]: [system] Activating service name='org.freedesktop.systemd1' (using servicehelper)
May 24 18:25:01 AsusLinux dbus[830]: [system] Successfully activated service 'org.freedesktop.systemd1'
May 24 18:25:01 AsusLinux colord: Device added: xrandr-H224W-H224WE840075
May 24 18:25:01 AsusLinux dbus[830]: [system] Activating service name='org.freedesktop.locale1' (using servicehelper)
May 24 18:25:01 AsusLinux dbus[830]: [system] Successfully activated service 'org.freedesktop.locale1'
May 24 18:25:02 AsusLinux colord: Automatic metadata add icc-987be6c27c09cf736bab2a1357e5009d to xrandr-H224W-H224WE840075
May 24 18:25:02 AsusLinux colord: Profile added: icc-987be6c27c09cf736bab2a1357e5009d
May 24 18:25:02 AsusLinux colord: Profile added: icc-d002a348bb4f91d5dfbd95a66a8e00b5
May 24 18:25:02 AsusLinux colord: Profile added: icc-f8a1a4269bfa519420117fce0143037b
May 24 18:25:02 AsusLinux colord: Profile added: icc-c6a16d1b80cd690ce8f19d5ff9e8c5ca
May 24 18:25:02 AsusLinux colord: Profile added: icc-dcc4bb6480e3130777216f557e101be1
May 24 18:25:02 AsusLinux colord: Profile added: icc-68f09c6b6b8ab1a1c1f9d62e5f798b19
May 24 18:25:02 AsusLinux colord: Profile added: icc-929fdf61afadd0d5b0d60da1f165f358
May 24 18:25:11 AsusLinux kernel: [ 4787.673998] [UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:52:22:00:1b:78:4c:50:f3:86:dd SRC=fe80:0000:0000:0000:021b:78ff:fe4c:50f3 DST=ff32:0000:0000:0000:0000:0000:0000:5222 LEN=104 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=21026 DPT=21026 LEN=64 
May 24 18:25:11 AsusLinux kernel: [ 4787.684043] [UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:52:22:00:1b:78:4c:50:f3:86:dd SRC=fe80:0000:0000:0000:021b:78ff:fe4c:50f3 DST=ff32:0000:0000:0000:0000:0000:0000:5222 LEN=104 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=21026 DPT=21026 LEN=64 
May 24 18:25:12 AsusLinux kernel: [ 4788.842212] [UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:52:22:00:1b:78:4c:50:f3:86:dd SRC=fe80:0000:0000:0000:021b:78ff:fe4c:50f3 DST=ff32:0000:0000:0000:0000:0000:0000:5222 LEN=104 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=21026 DPT=21026 LEN=64 
May 24 18:25:12 AsusLinux kernel: [ 4788.842231] [UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:52:22:00:1b:78:4c:50:f3:86:dd SRC=fe80:0000:0000:0000:021b:78ff:fe4c:50f3 DST=ff32:0000:0000:0000:0000:0000:0000:5222 LEN=104 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=21026 DPT=21026 LEN=64 
May 24 18:25:12 AsusLinux kernel: [ 4788.893287] [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:22:41:2a:f5:88:08:00 SRC=192.168.1.16 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=60066 PROTO=UDP SPT=54335 DPT=8612 LEN=24 
May 24 18:25:34 AsusLinux kernel: [ 4810.210204] [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:22:41:2a:f5:88:08:00 SRC=192.168.1.16 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=29806 PROTO=UDP SPT=52939 DPT=8612 LEN=24 
May 24 18:25:41 AsusLinux kernel: [ 4817.665708] [UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:52:22:00:1b:78:4c:50:f3:86:dd SRC=fe80:0000:0000:0000:021b:78ff:fe4c:50f3 DST=ff32:0000:0000:0000:0000:0000:0000:5222 LEN=104 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=21026 DPT=21026 LEN=64 
May 24 18:25:52 AsusLinux kernel: [ 4828.917774] [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:b8:26:6c:54:a1:16:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2 
May 24 18:26:11 AsusLinux kernel: [ 4847.668401] [UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:52:22:00:1b:78:4c:50:f3:86:dd SRC=fe80:0000:0000:0000:021b:78ff:fe4c:50f3 DST=ff32:0000:0000:0000:0000:0000:0000:5222 LEN=104 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=21026 DPT=21026 LEN=64 
May 24 18:26:15 AsusLinux kernel: [ 4851.848986] [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:22:41:2a:f5:88:08:00 SRC=192.168.1.16 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=36774 PROTO=UDP SPT=52752 DPT=8612 LEN=24 
May 24 18:26:30 AsusLinux colord: device removed: xrandr-H224W-H224WE840075
May 24 18:26:30 AsusLinux colord: Profile removed: icc-987be6c27c09cf736bab2a1357e5009d
May 24 18:26:30 AsusLinux colord: Profile removed: icc-d002a348bb4f91d5dfbd95a66a8e00b5
May 24 18:26:30 AsusLinux colord: Profile removed: icc-f8a1a4269bfa519420117fce0143037b
May 24 18:26:30 AsusLinux colord: Profile removed: icc-c6a16d1b80cd690ce8f19d5ff9e8c5ca
May 24 18:26:30 AsusLinux colord: Profile removed: icc-dcc4bb6480e3130777216f557e101be1
May 24 18:26:30 AsusLinux colord: Profile removed: icc-68f09c6b6b8ab1a1c1f9d62e5f798b19
May 24 18:26:30 AsusLinux colord: Profile removed: icc-929fdf61afadd0d5b0d60da1f165f358
May 24 18:26:31 AsusLinux acpid: client 1372[0:0] has disconnected
May 24 18:26:31 AsusLinux acpid: client connected from 9031[0:0]
May 24 18:26:31 AsusLinux acpid: 1 client rule loaded

Dernière modification par hr (Le 24/05/2015, à 20:02)

J5012 · Le 27/05/2015, à 02:41

la commande xhost permet d'utiliser l'identite de lightdm pour ouvrir une session shell : les applications lancees au demarrage de lightdm le sont par lightdm ...

voir l'usage de cette commande à : http://doc.ubuntu-fr.org/lightdm#change … ge_de_fond
section : Solution pour Ubuntu 12.04 Precise

hr · Le 27/05/2015, à 18:16

J5012 a écrit :

la commande xhost permet d'utiliser l'identite de lightdm pour ouvrir une session shell : les applications lancees au demarrage de lightdm le sont par lightdm ...

Ah, xhost pas xhoxt, oui ça je vois mieux de quoi il s’agit, même si je n’ai pas encore eu l’occasion de m’en servir. C’est le moment :
Une fois sous l’identité de lightdm, j’ai fait un ps -A pour voir tous les process qui lui appartiennent et je vais tuer tout ce qui n’est pas du standard. On verra bien ce que ça donnera.

hr · Le 27/05/2015, à 19:08

J’ai trouvé…
J’avais cherché dans tout ce que j’avais ajouté récemment sans m’occuper de ce que j’utilise depuis des années. Erreur.
C’était Diodon ! Le gestionnaire de presse-papier que j’utilise sur toutes mes machines en Ubuntu ou dérivés et qui ne m’a jamais osé de problème.

Problème 1 :
Comment puis-je me passer d’un presse-papiers multiple dans mon travail ? Réponse : je ne peux pas. Donc il faut que je trouve un remplaçant.

Problème 2 :
Est-ce bien lui ? C’est peut-être une incompatibilité, un conflit entre Diodon et quelque chose d’autre et pas Diodon en lui-même. Ayant supprimé tous les autres sauf Diodon ce qui n’a pas résolu le problème, j’aurais tendance à penser que c’est bien lui le coupable, mais c’est peut-être une analyse un peu rapide. Le système a en permanence des choses qui bougent et une mise à jour d’une obscure bibliothèque, dans un tréfonds au bout du couloir à droite, a pu déclencher un bug dans Diodon.

Bref, le problème est cerné et il me reste à le résoudre complètement. Je peux donc mettre ce fil en [RÉSOLU]
Merci à tous ceux qui se sont intéressés à cet obscur casse-tête !

moko138 · Le 28/05/2015, à 04:37

Comment as-tu identifié diodon comme fauteur de troubles ?

Des gestionnaire de presse-papier, il y en a plusieurs (clipit etc.). synaptic te les indiquera.

hr · Le 28/05/2015, à 08:47

Si j’avais été malin j’aurais pu gagner du temps mais, comme je l’ai dit, le problème n’étant apparu que récemment, j’ai supposé qu’il était causé par un ajout récent, serveur ou autre tournant en arrière plan.
J’ai appliqué la méthode de J5012 pour passer dans en terminal en compte lightdm et de là j’ai listé tous les process qui découlaient de lightdm, ce qui comprend aussi tout ce qui est lancé par la session.

Ayant fait un killall de tout ce qui n’était pas le système de base, j’ai pu refermer la session instantanément. Je me suis demandé comment trouver lequel de tous ces process était le bon et j’ai commencé par la manip la plus simple, quitter tous les indicateurs ce qui a mis en évidence que c’était l’un d’entre eux. Restait à resserrer la recherche jusqu’à arriver à arrêter Diodon seul et constater que c’était bien lui.
Désinstallé Diodon, re-testé : impec. Tant pis pour l’icône en trombone que j’aimais bien…

Pour remplacer Diodon j’ai opté pour Glipper qui me semble au moins aussi bien et dont le raccourci clavier réagit bien mieux que celui de Diodon qui restait souvent sans effet.
Bref, affaire close mais ça reste un peu flou dans la mesure où Diodon ne pose pas de problème sur mes autres machines. Mais elles sont soit en Ubuntu 15.04 soit en Xubuntu 14.04, donc pas dans les mêmes conditions.

hr · Le 12/04/2016, à 11:11

Le bug de Diodon qui se manifeste en version 1.3.x est enfin corrigé en 1.4.
Cette 1.4 est disponible sur ppa:diodon-team/stable pour Ubuntu trusty 14.04 et suivants sauf xenial 16.04… Gênant, la 1.3 étant dans la pratique difficilement utilisable en raison de ce fichu blocage de la fermeture de session.

En 16.04 j’utilise provisoirement le PPA de wily 15.10 mais le paquet du dépôt universe de xenial sera peut-être, espérons-le tout au moins, disponible à la sortie officielle de xenial dans quelques jours.

febcrash · Le 09/05/2016, à 16:28

J'avais le même problème en 1.3.0 depuis que je suis sous Xenial
Je viens d'ajouter le PPA diodon-team/stable et maintenant je ne rencontre plus le problème en version 1.5.0

MERCI hr !!!

Dernière modification par febcrash (Le 09/05/2016, à 16:29)

hr · Le 09/05/2016, à 23:41

Mille excuses ! J’avais effectivement oublié de mettre à jour le fil et de signaler que le PPA de xenial était sorti entre-temps…
Merci de l’avoir fait !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 22/04/2015, à 12:59

Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#2 Le 22/04/2015, à 13:14

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#3 Le 22/04/2015, à 18:39

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#4 Le 22/04/2015, à 19:26

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#5 Le 22/04/2015, à 19:31

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#6 Le 21/05/2015, à 00:58

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#7 Le 21/05/2015, à 01:13

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#8 Le 21/05/2015, à 03:58

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#9 Le 21/05/2015, à 09:06

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#10 Le 21/05/2015, à 11:56

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#11 Le 21/05/2015, à 12:11

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#12 Le 21/05/2015, à 17:27

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#13 Le 21/05/2015, à 18:18

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#14 Le 22/05/2015, à 09:14

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#15 Le 24/05/2015, à 18:37

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#16 Le 27/05/2015, à 02:41

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#17 Le 27/05/2015, à 18:16

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#18 Le 27/05/2015, à 19:08

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#19 Le 28/05/2015, à 04:37

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#20 Le 28/05/2015, à 08:47

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#21 Le 12/04/2016, à 11:11

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#22 Le 09/05/2016, à 16:28

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

#23 Le 09/05/2016, à 23:41

Re : Fermeture de session laborieuse [RÉSOLU] - dû à Diodon < 1.4

Pied de page des forums