Je pensais que ça n’était qu’un extrait.
Il date du 24 janvier, j’imagine que le dernier lancement de ta session graphique (désormais fonctionnelle) est postérieur à cette date.
Le truc visible qu’il raconte c’est “manque d’espace”, mais tu dis en avoir libéré justement en virant ce même fichier.
Un:
… éclaircira la situation.
Donc le but du jeu est d’avoir un xsession-errors récent, pour voir si tes messages se produisent encore, sachant qu’il ne devrait pas se plaindre de manque d’espace.
*.xsession-errors et .xsession-errors-old, tu mentionnes deux fichiers différents.
Si tu n’en as liquidé qu’un, il est aisément imaginable que le second soit toujours aussi volumineux.
Ou encore, tu n’en as liquidé aucun à cause de ce qui suit :
Tu n’aurais pas par inadvertance liquidé le fichier .xsession-errors* de ton $HOME du système Xubuntu ?
Celui que tu dois liquider se trouve en ton $HOME du système debian . Ce qui veut dire que la partition debian contenant $HOME devra être préalablement montée.
Ex :
$ sudo mkdir /debhome
$ sudo mount /dev/sdb6 /debhome
Pour /home séparé de la racine debian
$ cd /debhome/docanski
ou
/home solidaire de la racine debian
$ cd /debhome/home/docanski
Puis liquidation.
[quote=“etxeberrizahar”]*.xsession-errors et .xsession-errors-old, tu mentionnes deux fichiers différents.
Si tu n’en as liquidé qu’un, il est aisément imaginable que le second soit toujours aussi volumineux.
Ou encore, tu n’en as liquidé aucun à cause de ce qui suit :
Tu n’aurais pas par inadvertance liquidé le fichier .xsession-errors* de ton $HOME du système Xubuntu ?
[/quote]
Non, non, pas de problème : je n’ai pas fait la confusion.
Désormais, les fichiers .xsession-errors et .xsession-errors-old de Wheezy passent automatiquement vers /dev/null après un
[code]
[quote=“Zbf”]Je pensais que ça n’était qu’un extrait.
Il date du 24 janvier, j’imagine que le dernier lancement de ta session graphique (désormais fonctionnelle) est postérieur à cette date.[/quote]
Oui, bien entendu mais avant cela, ce fichier était à peu près le même à chaque nouvelle session.
[quote=“Zbf”]Le truc visible qu’il raconte c’est “manque d’espace”, mais tu dis en avoir libéré justement en virant ce même fichier.
Un:
df -h… éclaircira la situation.[/quote]
Voici :
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 29G 27G 441M 99% /
udev 10M 0 10M 0% /dev
tmpfs 385M 632K 384M 1% /run
/dev/disk/by-uuid/8cc77e96-3609-46e7-91e9-1548e1de7468 29G 27G 441M 99% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 969M 0 969M 0% /run/shmBizarre, non !? alors que les 2 fichiers incriminés sont à 0.
Il n’y a plus de xsession-errors ni de xsession-errors-old ou plutôt ils ne “pèsent” désormais plus que 0 octets, renvoyés vers /de/null … qui est aussi à 0 octet.
Ce qui est toutefois étonnant, c’est que le code ci-dessus signale qu’il ne reste pratiquement plus d’espace. 
Tu es bon pour un nettoyage, il y a eu d’autres topics récemment qui expliquent comment repérer ce qui prend de la place.
S’il s’agit des fichiers dans [mono]/var/log[/mono], voir lequel se remplit, et pourquoi (cette fois-ci, on ne fait pas disparaitre les symptomes en le balaçant vers /dev/null)
Quelques commandes, notamment:
… y sont indiquées.
Il est un peu dommage que ton / et ton /home ne soient pas séparées mais sur un ordi portable à espace limité je comprends ; 30Go c’est peu pour les 2 (pour être un peu tranquille il faut au moins 15 Go pour /) à moins que tu stockes tes films/mp3/documents sur une partition autre.
Mmmmh ça sent l’omelette norvégienne avec une install d’un paquet tiers à la mano et peut être des dépendances sur xorg qui ont secoué le système.
En console logue toi en root et passe la commande lightdm et regarde ce que dit la console.
Si ça ne marche pas, toujours en root passe la commande service lightdm stop, reboot.
[quote=“Zbf”]
S’il s’agit des fichiers dans [mono]/var/log[/mono], voir lequel se remplit, et pourquoi (cette fois-ci, on ne fait pas disparaitre les symptomes en le balaçant vers /dev/null)[/quote]
/var/log totalise moins de 500 Mo
J’observe notamment ceci dans /dev : environ 150 fichiers de 0 octets de type “périphérique de caractères et périphériques de blocs”. Ils sont tous datés d’aujourd’hui. Des tty (69 !), des vcs, des vcsa, des sda, des loop et d’autres moins nombreux dont le propriétaire est root.
L’espace libre (indiqué par le gestionnaire de fichiers) est de 437,5 Mo alors que la taille de partition est de 29,29 Go.
L’espace libre (indiqué par GParted) est de 1,89 Go.
Or, la totalité du système, des applications et des fichiers est inférieure à 10 Go.
[quote=“Zbf”]Quelques commandes, notamment:
… y sont indiquées.[/quote]
La réponse est 23 G
C’est le cas. Seuls le système, les applications et les documents que j’utilise le plus couramment se trouvent sur cette partition, le reste est stocké dans une autre partition.
[quote=“Triangle”]
En console logue toi en root et passe la commande lightdm et regarde ce que dit la console.[/quote]
Rien
Heu … là ça va provoquer un redémarrage de la bête, non !? Et que se passe-t’il ensuite ? Car j’aimerais comprendre d’abord, agir ensuite. Enfin … si c’est à ma portée, évidemment.
Je me suis trompé, la commande intéressante est plutôt:
du -sh /*Peu importent les fichiers de /dev, ils sont virtuels.
Salut
Tout a l’air normal :
7,4M /bin
18M /boot
0 /dev
7,2M /etc
4,3G /home
0 /initrd.img
136M /lib
4,0K /lib64
16K /lost+found
12K /media
4,0K /mnt
4,0K /opt
du: impossible d'accéder à « /proc/4150/task/4150/fd/3 »: Aucun fichier ou dossier de ce type
du: impossible d'accéder à « /proc/4150/task/4150/fdinfo/3 »: Aucun fichier ou dossier de ce type
du: impossible d'accéder à « /proc/4150/fd/3 »: Aucun fichier ou dossier de ce type
du: impossible d'accéder à « /proc/4150/fdinfo/3 »: Aucun fichier ou dossier de ce type
0 /proc
11M /root
628K /run
7,6M /sbin
4,0K /selinux
4,0K /srv
0 /sys
40K /tmp
3,7G /usr
461M /var
0 /vmlinuzEn effet, mais alors qqch m’échappe,
Et dans tes résultats là, tu as:
Un [mono]/home[/mono] de 4.5 Go
Un [mono]/usr[/mono] de 4 Go
Un [mono]/var[/mono] de 500 Mo
… ça fait à tout casser 10 Go.
Or [mono]df -h[/mono] indique 27 Go de pris.
Est-ce dû à une configuration particulière des partitions ? LVM (je ne suis pas familier avec) ?
Chez moi si je fais l’addition des principaux répertoires, je tombe sur les mêmes résultats que [mono]df[/mono]. Donc bien que y’ait:
Note: on peut évincer les messages d’erreur en les redirigeant comme suit:
[quote=“Zbf”]En effet, mais alors qqch m’échappe,
Est-ce dû à une configuration particulière des partitions ? LVM (je ne suis pas familier avec) ?
[/quote]
Non, partition tout-à-fait normale créée à l’origine avec GParted en ext4, voisine d’une ext3 pour Xubuntu, fat32 pour Ouindo$e et un swap de 1Go.
Envisageant d’agrandir la partition qui semble pleine à ras bord (il me reste près de 400 Go non alloués sur le disque), j’ouvre GParted où je constate qu’il me reste là 20,10 Go (69 %) non utilisés dans mon ext4 sur les 29,29 Go disponibles !
C’est donc totalement contradictoire par rapport aux autres tests.
Si j’en crois cette application, il n’y a donc rien, ou pas grand-chose, à nettoyer.
D’ailleurs, le système fonctionne parfaitement et sans ralentissement.
Mais bon, il y a un problème, c’est évident. Encore faut-il le trouver et le régler.
D’autant qu’un du -sh /* 2> /dev/null effectué à l’instant me fait récupérer l’espace perdu !
Cela n’a aucun sens.
Un topic qui semble similaire: crunchbang.org/forums/viewtopic.php?id=29466
Je pensais aussi à te conseiller de faire un [mono]fsck[/mono] sur cette partition depuis ton autre système. La personne ici a réinstallé le système pour régler le problème, il y aurait sans doute mieux à faire…
Edit: Tant que [mono]df -h[/mono] indique 99%, il faut le croire et penser que ta partition est quasi-pleine, ça n’empêche pas le système de fonctionner mais quelques 500Mo en plus et ça peut mener à des plantages (fort heureusement bénins). Le résultat de [mono]du[/mono] me paraît un chouillat optimiste en fait, difficile à dire.
Je n’ai pas vraiment envie d’en arriver là. Sinon pourquoi s’être décarcassé pendant une semaine pour trouver le problème.
D’autant que pratiquer une solution à la Ouindo$e n’est pas vraiment digne d’un linuxien.
J’ignore si tu as lu mon message précédent en totalité car je l’ai édité … peut-être pendant que tu écrivais ta réponse. Voir le -> dev/null
Oui j’ai vu, mais pas compris la fin de ton message.
Tu peux toujours recoller le résultat s’il a changé.
J’ai redémarré la machine et ledu -sh /* 2> /dev/nullest persistant : je retrouve l’espace libre comme il l’était avant mes déboires.
Mais il me semble que c’est un emplâtre sur une jambe de bois car cela n’a toujours pas permis de trouver l’origine du problème. Heu … je sais, je me répète mais je n’aime pas trop ne pas comprendre quand je me retrouve devant de telles situations. 
Ceci dit, je peux toutefois m’estimer satisfait en ayant évité une réinstallation toujours frustrante. Ce n’est donc qu’un demi échec … 
Merci pour ton aide tout au long de ce calvaire ! 
PS :
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 29G 8,8G 19G 32% /
udev 10M 0 10M 0% /dev
tmpfs 385M 632K 384M 1% /run
/dev/disk/by-uuid/8cc77e96-3609-46e7-91e9-1548e1de7468 29G 8,8G 19G 32% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 969M 0 969M 0% /run/shm
pour le dernier test.
Je ne comprends toujours pas bien,
Peux tu poster les résultats de:
… ce sera plus simple à interpréter.
Edit: ok, c’est fait pour df -h. Effectivement, çe me paraît bon…
J’ai édité et complété mon message précédent avec le 1er test.
Le second donne ceci :
7,4M /bin
18M /boot
0 /dev
7,2M /etc
4,3G /home
0 /initrd.img
136M /lib
4,0K /lib64
16K /lost+found
12K /media
4,0K /mnt
4,0K /opt
0 /proc
11M /root
632K /run
7,6M /sbin
4,0K /selinux
4,0K /srv
0 /sys
32K /tmp
3,7G /usr
462M /var
0 /vmlinuz
D’acc,
la colonne Utilisé indique 8,8G. Donc c’est bon c’est redevenu cohérent avec le résultat de [mono]du[/mono].