• LINUX > le fichier .xsession-errors

      réduire la taille de $HOME/.xsession-errors

      Éliminer les erreurs ne va pas réduire la taille du fichier. Par contre ça va empécher qu’il ne grossisse. Dans l’immédiat, pour réduire la taille tu peux faire un truc genre "echo -n > ~/.xsession-errors". Ce qui n’empéche pas d’essayer de corriger les erreurs.
      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
      Pas besoin de echo, ceci est suffisant:
      > ~/.xsession-errors
      $ rm ~/.xsession-errors
      $ ln -s /dev/null ~/.xsession-errors
      Certains signalements similaires sur internet parlent de plusieurs GOs, ce qui n’est pas très confortable pour une partition montée par NFS.
      si tu as plusieurs Go d’erreurs il faut vraiment analyser ce que c’est comme erreur vider le fichier n’aura que peu d’importance et la methode a deja été donnée
      ici, pour une machine qui tourne 8 à 10h par jour,
      mon fichier fait :
      user@host$cat .xsession-errors
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.

       

      et c’est tout.

       

      Tu utilise quel programme pour gérer lancer ta session ?

      GDM (qui a migré à FreeDesktop au passage donc plus de .xsession-errors, mais un .cache/gdm/session.log) réinitialise le fichier à chaque démarrage, c’est ça qui limite sa taille, bon après si t’a des sessions très longues ou beaucoup d’erreurs ça peut ne pas suffire.

      KDM (qui rotate aussi le fichier si je me rappelle bien) permet de modifier l’emplacement de ce fichier, vers un dossier local réservé eux logs par exemple, où /dev/null qui peut être une bonne idée sur un terminal en pur NFS.

       

      EDIT Tardif: Sinon la combinaison de SystemD et GDM fait exactement ce que tu cherche, les logs de la session vont dan un journal dont la taille est contrôlée par la configuration de journald.

       

      Je te remercie de cette excellente réponse : effectivement .xsession-errors peut avoir tendance à grossir en fonction des applis qu’on utilise et de leur tendance à balancer ou non des messages de debug : du coup, à part recompiler les applis (ça peut se faire mais ça réduit l’intérêt d’une distrib) le mieux est de parvenir à déplacer le fichier vers un support de stockage adapté.

      --

      How to prevent the .xsession-errors file from growing to a huge size

      The .xsession-errors file is where the X Window system logs all errors that occur within the Linux graphical environment. All desktop environments, whether Gnome, KDE, Cinnamon, XFCE, LXDE, etc., and all lighter window managers like FVWM, IceWM or Window Maker make use of the X Window system. Therefore any graphical application running on your computer can cause that error messages are written to the .xsession-errors file, reason why it can grow wildly until reaching very big sizes of tens of GB or even hundreds if your disk capacity allows it.

      Just as this problem affects different desktop environments and window managers based on X Window (that is, all of them), all Linux distributions, whether Ubuntu, Fedora, Debian or ArchLinux can also be affected.

      Although there is a control mechanism in the /etc/X11/Xsession file that causes the file to be emptied each time the graphical environment starts up if it exceeds a certain size, if you are one of those who, like me, normally suspend the computer instead of powering it off when the working day ends, it may be that you don’t restart your computer for weeks or even months, which means that the .xsession-errors file will never be truncated and can reach a gigantic size. And although you do frequently restart the system, it also happens that some applications, whether due to some type of failure/error or because they misuse the error log, start to send uncontrolled thousands and thousands of messages to .xsession-errors.

      The .xsession-errors file is usually located in your home directory and the only problem it should cause is that your personal folder is full. But if you have not partitioned your disk properly and only have one partition for the entire root (/) file system, the fast growth of .xsession-errors can cause your computer to stop working and crash.

      Further reading:  The importance of properly partitioning a disk in Linux

      Empty the .xsession-errors file

      If it already happened that you ran out of disk space and using the du -k /home | sort -n | tail -5 command you were able to determine that the .xsession-errors file is the one that takes up more space, the first step to fix the problem is to empty it completely:

      $ >~/.xsession-errors

      Prevent .xsession-errors from growing out of control

      Once the space is freed, you will want this situation not to be repeated again in the future. To achieve this it is best to try to find the origin of the problem, ie, to know which process is writing uncontrolled to the error log and why. For this you can use the fatrace command as indicated in this other post: Fatrace command: how to know in real time which processes are writing to a file.

      Another interesting measure to adopt is to add a task to your crontab to periodically check the size of .xsession-errors file. If it exceeds a certain threshold, empty or truncate it so that only the last lines are retained:

      – Example #1: Check every 15 minutes if the file size is greater than 5 GB and if so empty it:

      */15  *  *  *  *  [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 5000000 ] && >/home/$(whoami)/.xsession-errors

      – Example #2: Do the same check, but instead of emptying the entire log, keep the last 10,000 lines:

      */15  *  *  *  *  [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 5000000 ] && tail -10000 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors

      Disable writes on .xsession-errors file

      If you want to forget about this log because in normal operation you are not interested in its debugging information, you can redirect to /dev/null everything that is written to it and thus always keep a size of 0 bytes. For this you can edit the /etc/X11/Xsession configuration file of the X Window system and locate the following line:

      ERRFILE=$HOME/.xsession-errors

      Replace it with:

      ERRFILE=/dev/null

      You can also delete the .xsession-errors file and create a symbolic link to /dev/null instead in order to get the same result:

      $ rm .xsession-errors
$ ln -s /dev/null .xsession-errors

      The problem is that when you restart the session the symbolic link will be replaced back by a regular file and will start to grow again. To avoid this you must add the following lines to the .bashrc script in your home directory:

      # If the .xsession-errors file is not a symbolic link, delete it and create it as such
if [ ! -h $HOME/.xsession-errors ]; then
 /bin/rm $HOME/.xsession-errors
 ln -s /dev/null $HOME/.xsession-errors
fi

      Finally, there is another way which consists in setting the immutable attribute to the file, which will prevent to write anything to it by any user or process. This can cause system unexpected behavior, so it should be done with caution:

      $ sudo chattr +i .xsession-errors

      --

      Bonjour,

      Extrait de (ce post) :

      Dans /etc/X11/Xsession, il faut commenter la ligne: ERRFILE=$HOME/.xsession-errors et ajouter celle-ci en dessous:
      ERRFILE=/tmp/$USER-xsession-errors

      J’ai utilisé un temps :

      ERRFILE=/tmp/$USER-xsession-errors

      Avec tmp en mémoire vive.

      # /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=b3ffbc0f-5e70-4ee2-91fa-ee050196a503 /               ext4    noatime,discard,commit=60,errors=remount-ro 0       1
# /home was on /dev/sda3 during installation
UUID=5e733759-2667-437b-9fc2-a75ae8fecca3 /home           ext4    noatime,discard,commit=60       0       2
# swap was on /dev/sda2 during installation
UUID=7619d8e3-8318-4b68-8b6f-6361b122e842 none            swap    sw              0       0
tmpfs	/tmp            tmpfs		defaults,size=1g	0	0

      A+

      lynn

      Bonjour,

      Une solution de contournement qui fonctionne; J’ai mis ces quelques lignes à la fin du fichier bash.bashrc situé dans /etc

      if [ ! -h $HOME/.xsession-errors ]
then
    /bin/rm $HOME/.xsession-errors
    ln -s /dev/null $HOME/.xsession-errors
fi

if [ ! -h $HOME/.xsession-errors.old ]
then
    /bin/rm $HOME/.xsession-errors.old
    ln -s /dev/null $HOME/.xsession-errors.old
fi

      C’est peut-être un peu radical mais je suis confrontée à ça sur une installation d’Ubuntu 13.04 que j’ai faite sur le pc de mes parents alors que ce problème n’existait pas avec la version précédente. Le /home de 300 Go se remplissait totalement

      Sur mes autres pc personnels ( fixes ou portables ), je n’ai pas ce problème… pour l’instant.

      «C’est pas parce qu’ils sont nombreux à avoir tort qu’ils ont raison!»

      Coluche

      moko138
      Berzingh a écrit : 

      Mmmh, je ne dois pas être réveillée, mais je ne vois pas trop le rapport avec fsck.

      Le rapport, c’est que fsck avait résolu mon problème qui était dû au gonflement de .xsession-errors.

      Un utilitaire précieux : ncdu
      Photo, mini-tutoriel :  À la découverte de dcraw

      Berzingh

      Merci pour ces solutions. Pour diverses raisons, j’ai dû réinstaller mon Ubuntu. Comme j’avais des trucs urgents à faire, je n’ai pour l’instant pas installé Chrome et m’en suis tenue à Firefox… mais rebelote : xsession-errors qui caracolait vers les 200Go… Comme je n’avais pas forcément envie de tenter le /tmp en mémoire vive ou de découvrir les effets de bord d’un tmp plein la gueule, j’ai appliqué la solution un peu drastique de lynn, qui marche pour l’instant parfaitement.

      Quand j’aurais le temps, j’essayerai de résoudre la cause de ces logs intempestifs…

      Encore merci à tous.

      Berzingh

      Rebonjour,
      Finalement, mon problème n’est pas résolu. J’ai le même phénomène que lorsque j’avais verrouillé les accès à .xsession-error et .xsession-error-old : ces deux-là gardent une taille constante, mais ma partition /home persiste à se remplir jusqu’à saturation…

      J’ai tenté un :

      find /home -size +100M

      Mais sans succès.

      Maintenant, j’ai donc deux problèmes :
      - réussir à vider mon /home,
      - réussi à juguler la croissance des logs de X11.

      Des idées ? Le premier problème est assez critique. Concernant la solution de michel_04, si je mets tmp en mémoire vive, est-ce que ça ne risque pas de saturer ma mémoire ?
      Merci d’avance pour votre aide.

      Dernière modification par Berzingh (Le 25/06/2013, à 12:14)

      malbo

      Essaie de remplacer Lightdm par GDM pour voir si ça peut éviter la "croissance des logs de X11″ : j’indique comment faire dans l’item 2 de ce post : http://forum.ubuntu-fr.org/viewtopic.ph … 1#p9231161

      --

      EOF permet de débuté les multi-lignes, jusqu’à ce que tu redonnes un EOF.

      Donc à la première ligne tu fais enter, tu continues sur la ligne suivante (donc ici tu écris le contenu de la ligne 2), à la troisième EOF qui termine.

      Le fichier .xsession-errors est utile.
      Je le regardes aux débuts de l’installation du système et les logiciels qui démarre pour la première fois.
      Sa permet de vite voir s’il y a une chose manquante.

      Et de temps en temps vérifier s’il y a un soucis avec les logiciels utilisé.

      Ayant un ssd sa peut-être utile, j’ai en ce moment 15k lignes  (édite déjà 17k, je me demandes si c’est un fichier .xsession-Errors ou .xsession-Logs hmm)

      Merci !
      Et pourtant, j’avais déjà posé la question, j’aurais dû m’en souvenir mais malheureusement, cette putain de mémoire fait de plus en plus défaut

      J’ai fait hier soir, fermé complètement la machine mais ce matin, xsession-errors est toujours présent

      Il fait quelle taille ? Normalement ça doit maintenant être un lien vers [mono]/dev/null[/mono] donc taille 0.
      Éventuellement vérifie avec [mono]ls -lA ~/.xsession-errors[/mono]

      [mono]ricardo@ordibureau:~$ ls -lA ~/.xsession-errors
      -rw——- 1 ricardo ricardo 42701 nov. 17 19:06 /home/ricardo/.xsession-errors[/mono]
      Je viens de rallumer à 19 H
      38.4 Kio mais il y a peu de temps que je tourne sur cette machine.

      :question:

       

      [mono]ricardo@ordibureau:~$ cat /etc/X11/Xsession.d/00disable-xsession-errors
      cat: /etc/X11/Xsession.d/00disable-xsession-errors: Aucun fichier ou dossier de ce type[/mono]

      Soit ta pas fait la manip ou mal fait, soit pas avec les bons droits.

      En root:

      • touch /etc/X11/Xsession.d/00disable-xsession-errors
      • echo ‘ln -fs /dev/null “$HOME”/.xsession-errors’ > /etc/X11/Xsession.d/00disable-xsession-errors

      (pour vérifier) ls -l /home/ricardo/.xsession-errors

      Soit ta pas fait la manip ou mal fait, soit pas avec les bons droits.

      J’ai remplacé ma commande multilignes par ton [mono]echo[/mono] simple, ça évitera les confusions à l’avenir.

      Bonjour,
      Est-ce que la suppression de ces données est réellement sûre? J´ai toujours été méfiant lorsqu´il fallait supprimer des données dont on ne savait pas à quoi elles servaient… Histoire que je ne me retrouve pas avec un système qui commence à planter haha

      Il ne s’agit ici que d’un fichier journal, qui ne contient pas de données utiles aux programmes mais uniquement une copie des différents messages d’erreur de la session graphique à l’usage de l’utilisateur.

      Pas de panique, ton système marchera très bien sans !

      Utilisez xinit au lieu de xsession et vous n’aurez plus le problème !

      Utilisez xinit au lieu de xsession et vous n’aurez plus le problème !

      Ouais bah mes KDE s’installent toujours avec [mono]xsession[/mono] donc je laisse comme ça, c’est bien plus simple de désactiver [mono]~/.xsession-errors[/mono] plutôt que d’essayer de basculer vers [mono]xinit[/mono] (à condition que ça soit faisable, pour commencer).

      Avec cette ligne modifiée, ça fonctionne : [mono].xsession-errors[/mono] = lien de 0 octet pointant sur [mono]/dev/null[/mono]

      super vv222  ca me rassure, oui ca n´a pas l´air trop important  J´accepte de m´en séparer haha

      Il vaut mieux

      touch /tmp/$(basename $HOME).xsession-errors ln -fs /tmp/$(basename $HOME).xsession-errors "$HOME"/.xsession-errors
      avec un /tmp en tmpfs. Cela permet de debugguer éventuellement un programme.

      Très bonne idée.
      Faut ajouter les deux méthodes dans le sujet, l’une pour garder le fichier de manière intelligente et l’autre pour désactiver tout court pour ceux n’ayant pas l’utilité.

      tmpfs c’est pour utiliser un dossier dans la ram si je me souviens bien.

      Mais je trouves pas mon /tmp dans /etc/fstab-mtab, pourtant /tmp semble être utilisé.
      Avant il était dans l’un des fichiers fstab ou mtab si je me rappelles bien.

      Même dans “mount” il ne s’affiche pas.
      Donc il se comporte comme un dossier normal du disque dur je crois.

      Hmm.

      @fran.b C’est pas bête tiens. Je rajoute ça dans mon post initial.

      kripteks : Tout ce que tu cherches se trouve du côté du fichier /etc/default/tmpfs

      7 mois plus tard

      Bonjour, j’ai redirigé xsession sur /dev/null, mais comment rétablir la situation maintenant ? La session se déconnecte automatiquement maintenant et il faut réentrer le mot de passe à chaque fois. Du coup si on modifier un fichier sur le serveur, à un moment on perd les modifications car on ne peut plus enregistrer les modifications.

      --

       

      --

       

      --

       

      --

       

 

Aucun commentaire

 

Laissez un commentaire