Vous n'êtes pas identifié(e).
Dernière modification par ubub (28-06-2022 20:13:14)
Hors ligne
e me dis que si je fais sauter la double architecture, j'aurais (deux fois moins)? de paquets...
Tous les paquets ne sont pas en double. Seuls les paquets installés avec une autre achitecture le sont éventuellement.
Y'a-til un delete architecture à contrario du add-architecture ?
Oui, mais il faut d'abord désinstaller tous les paquets de l'architecture.
Y'a-t-il un danger à effacer carrément /var/log ?
Oui, et je ne ferais pas ça.
Quels sont les logs les plus gros ? Quand ont-ils été créés (pour voir s'ils "tournent" régulièrement) ?
Si quelque chose y envoie des messages répétitifs, les supprimer ne fera que retarder l'inévitable, il faut s'attaquer à la source.
Il vaut mieux montrer que raconter.
Hors ligne
Oui, mais il faut d'abord désinstaller tous les paquets de l'architecture.
... j'ai fait, en fait j'ai suivi ceci:
si je suis assez confiant pour avoir viré les paquets i386, je me rends pas compte pour l'effacement de la double architecture ....
Y'a-t-il un danger à effacer carrément /var/log ?
Oui, et je ne ferais pas ça.
j'ai pas fait ...
Quels sont les logs les plus gros ?
de mon souvenir, un dossier nommé journal et un log nommé messages, 5,7 et 5,2 Go respectivement de souvenir, et syslog et user.log pesant à peu près 2.5 Go chacun...
Les ai tous giclé ...
Quand ont-ils été créés (pour voir s'ils "tournent" régulièrement) ?
ah beh ça j'ai pas pensé à regarder, maintenant ils ont disparus ...
syslog et user.log ont été recrées depuis, pas journal ni messages
Hors ligne
si je suis assez confiant pour avoir viré les paquets i386, je me rends pas compte pour l'effacement de la double architecture
La double architecture, ce n'est que la possibilité d'installer des paquets d'une autre architecture, rien de plus.
Les ai tous giclé
S'ils recommencent à grossir anormalement, il faudra regarder dedans.
Le répertoire (et non dossier, ce n'est pas la même chose) /var/log/journal contient les logs de systemd, il faut passer par journalctl pour les manipuler.
Dernière modification par raleur (27-06-2022 11:43:56)
Il vaut mieux montrer que raconter.
Hors ligne
La double architecture, ce n'est que la possibilité d'installer des paquets d'une autre architecture, rien de plus..
donc en virant wine32 et le jeu qui en dépendait, plus personne ne devrait demander de paquets i386 ..? résolu pour ça alors,
Hors ligne
y'aurait-il un outil pour voir qui bouffe tout l'espace
J’utilise ncdu pour ça :
---
donc en virant wine32 et le jeu qui en dépendait, plus personne ne devrait demander de paquets i386 ..?
Tu peux vérifier s’il te reste des paquets i386 installés avec :
Pour chacun des paquets installés, tu peux connaître les raisons de son installation avec :
Hors ligne
Bonjour,
[…]
de mon souvenir, un dossier nommé journal et un log nommé messages, 5,7 et 5,2 Go respectivement de souvenir, et syslog et user.log pesant à peu près 2.5 Go chacun...
Les ai tous giclé ...
Quand ont-ils été créés (pour voir s'ils "tournent" régulièrement) ?
ah beh ça j'ai pas pensé à regarder, maintenant ils ont disparus ...
syslog et user.log ont été recrées depuis, pas journal ni messages
Bonjour ! Comme tu as supprimé journal dans /var/log/, je pense qu'il est probable qu'il est recréé maintenant dans /run/log/, en tout cas, c'est le comportement prévu par journald.conf si l'option Storage est à persistent ou à auto, voir man journald.conf
ou :
Tu peux vérifier son emplacement actuel et l'intégrité des fichiers journaux avec :
La taille totale des fichiers journaux :
Le problème, c'est que les fichiers journaux vont continuer à regrossir, mais dans /run/log/ si je raisonne bien. Le mieux est de configurer de manière adéquate journald.conf de telle manière que ceci n'arrive plus ( le dossier journal à 5,7 Go ! ).
Dans /etc/systemd/journald.conf, il faut passer la ligne :
#SystemMaxUse=
à
SystemMaxUse=50M
ou approchant, 100M, 200M, c'est toi qui voit ! C'est la taille limite que prendra le dossier journal.
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
Hors ligne
Comme tu as supprimé journal dans /var/log/, je pense qu'il est probable qu'il est recréé maintenant dans /run/log/, en tout cas, c'est le comportement prévu par journald.conf si l'option Storage est à persistent ou à auto
Seulement avec l'option par défaut Storage=auto. Avec Storage=persistent, /var/log/journal est recréé si nécessaire et les logs sont écrits dedans. Ce n'est que si c'est impossible (/var/log en lecture seule) que les logs sont écrits dans /run/log/journal.
je me suis demandé, passer storage (actuellement auto) à volatile, stockerait tout en mémoire ..?
En utilisant le swap si nécessaire.
Il vaut mieux montrer que raconter.
Hors ligne
Merci pour ces conseils,
super pratique ncdu; il m'en reste plein de paquets i386 ...
Le journal s'est bel est bien recréé dans /run/log , il est à 4,7Mo pour l'instant,
je l'ai limité à 100M, je n'ai aucune idée d'un chiffre réaliste, j'imagine que là c'est beaucoup trop, mais c'est pour voir l'évolution...
...je me suis demandé, passer storage (actuellement auto) à volatile, stockerait tout en mémoire ..? Et bloquerait aussi l'ordi avec une mémoire pleine ? même si celle ci est vidée j'imagine à chaque éteignage de l'ordi ...évitant l'accumulation ...
à ubub, j'ai mis 50M et je peux voir suffisamment loin en arrière ( à mon goût ), tant et si bien que je l'ai aussi limité à une semaine de rétention car j'ai aussi mis le paramètre MaxRetentionSec=1week
mais c'est personnel, à toi de voir tes usages du journal. Mets un chiffre et vois l'évolution, regarde si le journal remonte suffisamment loin en arrière pour toi.
Passer Storage à volatile pour le mettre en RAM ? À mon avis, ce n'est pas une bonne idée puisque courant coupé, tout le journal sera perdu. En cas de plantage, tu n'auras plus de log du journal de la session qui a planté, cela serait passer d'un extrême de conservation ( qui a rempli ton système ) à un extrême de non-conservation qui ne va pas t'aider à trouver la cause du plantage.
Édition ! : Je m'aperçois qu'il faut mettre Storage à persistent si l'on veut garder la trace d'un plantage ! Pas assez réfléchi !
à raleur, tu as raison, à la relecture ta compréhension pour Storage=persistent m'apparaît plus détaillée et précise que la mienne and if the disk is not writable.
Dernière modification par --gilles-- (27-06-2022 17:05:17)
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
S'ils recommencent à grossir anormalement, il faudra regarder dedans.
Et il faut regarder quoi ?
En fait, journal dans /run/log a déja atteint 48 Mio, en qq heures, mais ...
dans /var/log ça va pas du tout
Hors ligne
J'ai débloqué le paramètre max_burst ou un nom comme ça, qui si j'ai bien compris, limite les messages à 1000 ou 10000 dans un laps de temps de qq secondes (30 je crois était écrit)...
comme quoi, 50 Mio pour journal, ils sont entrain d'être pulvérisés...
Hors ligne
Est-ce que tu as aussi les messages et les user.log comprimés par gzip ?
J'ai débloqué le paramètre max_burst ou un nom comme ça
Cette affirmation n'est pas assez précise : quel est le bon nom de max_burst, dans quel fichier de configuration l'as-tu modifié ?
Respire, reste calme, prends des notes, cela t'aidera et cela nous aidera.
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
Dernière modification par --gilles-- (27-06-2022 21:53:37)
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
mais de tout façon je me suis planté, lu trop vite, journal est à 4,8Mio
tant qu'aux autres logs (syslog, user.log et messages) je les ai supprimé, ils étaient à 6,4 Gio chacun ...
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Désactiver les miniatures des vidéos
Par défaut, Thunar analyse chaque élement sur votre disque dur et médias connectés, peu importe la taille. Ce qui peut conduire à certains ralentissements. Copiez le fichier tumbler.rc dans votre ~./config/tumbler/ :
Pour désactiver l'analyse des films, désactivez les modules ffmpegthumbnailer et GStreamer:
Hors ligne
Hors ligne
Si tu confies la gestion de tes journaux à journald, je te conseille de ne pas avoir en plus de démon "traditionnel" syslog sinon tout va être stocké en double.
en fait j'ai pas compris grand chose à cette phrase ...
moi j'ai rien confié à personne ...
Est-ce que tu parles de l'effacement du fichier /var/log/journal qui est allé se reproduire sous /run/log ?
C'est très flou pour moi ces histoires de journaux, je pensais avoir atteint le fond avec les logs...
Je trouve peu d'info sur le répertoire /run ...
Run-time variable data: Information about the running system since last boot, e.g., currently logged-in users and running daemons. Files under this directory must be either removed or truncated at the beginning of the boot process, but this is not necessary on systems that provide this directory as a temporary filesystem (tmpfs).
bon, c'est un système de fichiers temporaire ? qui se recrée et donc s'autodétruit à chaque reboot ?
C'est vraiment pas bien ? perte des logs lors du reboot ..?
Pour ça que tu dis que c'est écrit deux fois ?
aargh, désolé, c'est encore un coté sombre et flou pour moi ...
Hors ligne
C'est très flou pour moi ces histoires de journaux, je pensais avoir atteint le fond avec les logs...
Journaux et logs c’est la même chose, "log" est le terme anglais et "journal" celui français
Hors ligne
Si tu n’as pas de préférence particulière sur le système à privilégier
C'est quoi l'action qui "privilégie" le système ?
Hors ligne
C'est quoi l'action qui "privilégie" le système ?
Tout simplement de désinstaller un des deux systèmes de gestion des journaux, et de laisser l’autre en place.
Hors ligne
Hors ligne
Journaux et logs c’est la même chose, "log" est le terme anglais et "journal" celui français
Je sais bien, mais je me suis demandé, que c'est-il passé dans l"esqprit de nos cousin(e)s anglophones pour donner deux noms à une même chose, ou deux mêmes choses ?
J'y ai soupçonné une subtile différence, journal n'est jamais utilisé en langue anglaise ...
Hors ligne
journald est celui par défaut sur Debian
En quoi systemd-journald est-il plus "par défaut" que rsyslog ? rsyslog est toujours installé par défaut par l'installateur de bullseye et activé.
Tout simplement de désinstaller un des deux systèmes de gestion des journaux
Ou bien le désactiver.
Ça ne serait pas un peu difficile de désinstaller systemd-journald qui fait partie du paquet systemd ?
si tu as les deux qui sont installés et actifs tu vas avoir la plupart de tes journaux stockés en double.
C'est déjà le cas avec (r)syslog seul : les messages du noyau vont à la fois dans kern.log, messages et syslog, les messages des démons vont à la fois dans syslog et daemon.log...
je comprends pas vraiment le danger, si "danger" il y a
Le "danger", c'est d'occuper deux fois plus d'espace disque et de le consommer deux fois plus vite en cas d'avanlanche.
Dernière modification par raleur (29-06-2022 22:56:06)
Il vaut mieux montrer que raconter.
Hors ligne