PC à genoux après la fermeture d'un jeu sous Debian 12?

Support Debian
#1

Bonjour,

Depuis la mise à jour vers Debian 12 (par réinstallation) de ma machine, un jeu mettait beaucoup de temps à se fermer, faisant monter la charge moyenne de la machine à plus de 120. J’ai récemment eu le même problème avec un autre jeu qui a planté et fait la même chose, mais ce plantage m’a fait comprendre ce qui n’allait pas.
Pendant le crash du jeu, j’ai eu une notification de l’environnement de bureau sur le manque d’espace disponible dans la partition du système. Après vérification des espaces occupés sur cette partition, j’ai trouvé le coupable.
Le dossier /var/lib/systemd/coredump prenait énormément de place et les noms des fichiers ne laissaient aucun doute sur la source du problème : au plantage, systemD génère un fichier plus ou moins volumineux quand il y a un plantage.
Le problème, c’est que le premier jeu est toujours détecté comme ayant crashé à sa fermeture, j’ai donc cherché comment régler le problème, et j’ai trouvé assez rapidement.

Je vais donc vous partager ici l’astuce que j’ai utilisée pour deux raisons :

  1. ça prend beaucoup trop de temps à générer et rend le système quasiment inutilisable pendant l’opération
  2. je ne sais pas à quoi ça sert et je soupçonne que ça ne me soit absolument inutile

J’ai donc modifié le fichier /etc/systemd/coredump.conf pour ajouter/modifier les options suivantes dans la section Coredump :

[Coredump]
Storage=none
ProcessSizeMax=0

Je n’ai pas trouvé quel service il fallait relancer, alors j’ai redémarré ma machine directement et le problème semble résolu.

#2

Bonjour,
C’est une réponse du type problème XY.
Pourquoi ton jeu plante? vu que c’est lui le responsable à la base?
Car en fait la cause du coredump n’est pas corrigé, tu te contente de dégrader le coredump.
ensuite, qu’elle est la taille de ton répertoire /var, ou de / ? (une solution pour éviter des problèmes systèmes à cause de coredump ou de logs c’est de faire une partition dédié pour /var et /var/log

#3

Pas un peu radical?

Surtout que tu pouvais compresser, reduire la size du dump ou encore le relocaliser

#4

D’accord, par contre, je ne sais pas comment répondre à cette question.

En fait, je vois un truc de presque 10 Gio (au moins, sa génération a été interrompue par l’absence de place) qui est nommé coredump. En vrai, je n’ai pas la moindre idée de ce que c’est, je vois juste que ça ne me sert à rien et que ça prendre BEAUCOUP de place. La question serait, plutôt que de savoir pourquoi le jeu a planté, de savoir pourquoi le coredump a besoin de prendre autant de place.

du me dit que /var prend 804 Mio.
Le dossier /var est sur la partition racine qui a une taille de 20 Gio et qui est remplie à 58 %.
Si je crée une partition dédiée pour /var, il y a de grandes chances que le jeu plante toujours et que ces fichiers coredump soient toujours générés. Ça deviendrait presque un problème XYZ…
Je vois aucun intérêt à créer une partition dédiée pour /var/log, l’utilisation de ce dossier est très marginale. rsyslog n’y enregistre rien et systemd-journald utilise la mémoire vive.

Si je le compresse, il est toujours stocké et je ne comprends pas mieux dans quel but.
Je ne vois pas comment réduire sa taille, sauf en ne le stockant pas.
Si je demande à le stocker ailleurs, il sera stocké ailleurs, mais il sera quand même stocké.

Pour rappel, pour vous deux, le problème que je rencontre, ce n’est pas le plantage du jeu, ce n’est pas l’espace disque utilisé par le fichier coredump. En vrai, si le jeu plante trop, j’arrête d’y jouer en attendant un correctif et si un programme a besoin d’espace pour stocker des trucs que je ne comprends pas ce que c’est (même si je préférerais quand même comprendre ce que c’est), je peux lui en attribuer un bon tébioctet s’il veut.
Le problème, c’est que la charge moyenne crève le plafond et que la machine est quasiment inutilisable environ une dizaine de minutes et que je considère que ce n’est pas un comportement normal.

#5

La fonction est le debug, analyse securité, analyse de performance, analyse qualité pour le dev de logiciel, etc
Si ca répond à votre question

Comme vous disez votre collègue vous avez cassé le thermometre pour ne pas voir que le patient a de la fièvre…façon de parler

edit: la solution pérène je pense, mais comme je mon cerveau est en mode « sleep » faut relativiser, serait de démarrer le system en mode debug et de regarder ce qu’il se passe qd le jeu « merde ». Mais peut etre avant il faudrait regarder les logs spécifiques au jeu

#6

Je n’ai aucune intention de transmettre ce truc au dev du jeu. Les deux jeux en question sont des jeux exclusivement pour Windows et pour lesquels le hasard (mais surtout le travail acharné des dev de Wine et de Valve) fait qu’il fonctionne avec Proton.
Autant te dire que si j’envoie ces trucs, le dev sa s’en tamponner l’oreille avec une babouche.
Du coup, ça m’enchante moyen de faire ramer mon PC pendant une dizaine de minutes pour remplir d’espace de stockage avec un truc qui ne servira à personne.

#7

Bah voilà il fallait commencer par ca… sourire

ps: vu que ca doit venir d’une m**** dans le developpement ca serait peut etre pas c** de transmettre le dump aux dev pour eviter que dans le futur d’autres joueurs rencontrent le meme pb.

#8

De quels jeux s’agit-il?

#9

merci pour ta solution almtesh
pour moi ce n’est pas un pb XY car la fièvre n’est pas la taille ou l’existence du fichier mais sa création , et qu’ne plus il ne pose pas de question mais propose une solution

la question de taille n’est indiquée que pour nous aider en cas de même pb : même avec 1000 To il aurait le même pb de « charge moyenne » ( la fièvre )

ton pb n’est pas le jeu ni même le fichier mais la création du fichier dont tu n’as que faire.

ta solution est un peu radicale, surtout si elle impacte d’autres programmes mais ça solutionne ton pb.

zargos fait des partitions séparés alors il le dit , et il a bien raison.

Tu pourrais vérifier à la fermeture du jeu si des programme .exe tournent encore et les tuer automatiquement à la fermeture.

#10

Je pense que ca vient de l’interface wine/valve et jeu d’où mon post
Les jeux développés pour win et mac ne tournent pas « seamlessly » sous linux c’est un fait

#11

Celui qui provoquait ça à chaque fermeture, c’est GTA V et celui qui ne l’a fait qu’une fois et qui m’a permis de trouver la cause du problème, c’est Marvel’s Spider-Man Remastered.
En plus, pendant la génération du coredump, le jeu était bloqué sur une cinématique et j’ai dû rester plus de dix minutes avec le visage de Peter Parker en gros plan. Au début, j’ai trouvé que la peau du visage était assez bien rendue, mais j’ai vite trouvé ça gênant.

#12

:rofl:

Tu lances le jeu comment? à travers Steam?

#13

Oui, j’ai acheté le jeu sur Steam, du coup, je le lance à travers Steam en utilisant Proton 8 comme outil de compatibilité.

#14

As tu essayé en proton expérimental? Car sur protonDB quelqu’un signalait que ça avait bien marché avec.