Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

MJ_Tistus · Le 30/04/2020, à 17:37

journalctl -f

pour l'instant ça donne :

-- Logs begin at Wed 2020-04-29 00:34:48 CEST. --
avril 30 17:24:50 tistus-PC systemd-resolved[961]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
avril 30 17:27:32 tistus-PC systemd-resolved[961]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
avril 30 17:30:01 tistus-PC CRON[8776]: pam_unix(cron:session): session opened for user root by (uid=0)
avril 30 17:30:01 tistus-PC CRON[8777]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
avril 30 17:30:01 tistus-PC CRON[8776]: pam_unix(cron:session): session closed for user root
avril 30 17:31:07 tistus-PC systemd[1]: Started Run anacron jobs.
avril 30 17:31:07 tistus-PC anacron[8781]: Anacron 2.3 started on 2020-04-30
avril 30 17:31:07 tistus-PC anacron[8781]: Normal exit (0 jobs run)
avril 30 17:31:07 tistus-PC systemd[1]: anacron.service: Succeeded.
avril 30 17:32:32 tistus-PC systemd-resolved[961]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

je suis entrain de regarder comment report des bugs

MJ_Tistus · Le 30/04/2020, à 18:15

Je précise au passage que si quelqu'un qui connaît bien l'outil de bug report d'Ubuntu vois ce fil, je ne suis pas contre de l'aide. C'est la première fois que je le fais donc je n'y connais rien.
EDIT par exemple je ne connais pas le package qui cause ce problème, ce dont launchpad a besoin. Qu'est-ce qui gère les journaux syslog ? c'est lui le fautif ?

Dernière modification par MJ_Tistus (Le 30/04/2020, à 18:21)

geole · Le 30/04/2020, à 18:23

Tu n'as peut-être pas qu'un seul problème.

Pour l'un, il est référencé https://bugs.launchpad.net/ubuntu/+sour … ug/1857392 c'est du style "on s'en fout"
Pour celui qui trace énormément, je n'ai rien trouvé. Pourvu qu'il n'y ait que deux problèmes

On a déjà débattu dans le forum sur la débilité de répéter toutes les secondes qu'il existe le même problème . C'était à propos des imprimantes en réseau.
Ce n'est pas syslog qu'il faut viser, il se contente de faire ce que l'application lui dit de faire.

Il me semble que le problème principal est dans cet extrait

avril 30 14:27:14 tistus-PC gnome-shell[2044]: JS ERROR: TypeError: this._workspacesViews[i] is undefined
                                               _updateWorkspacesFullGeometry@resource:///org/gnome/shell/ui/workspacesView.js:755:13
                                               setWorkspacesFullGeometry@resource:///org/gnome/shell/ui/workspacesView.js:745:14
                                               setWorkspacesFullGeometry@resource:///org/gnome/shell/ui/viewSelector.js:301:33
                                               _updateWorkspacesGeometry@resource:///org/gnome/shell/ui/overviewControls.js:496:27
                                               vfunc_allocate@resource:///org/gnome/shell/ui/overviewControls.js:401:14
                                               _computeWindowCenter@resource:///org/gnome/shell/ui/workspace.js:302:35
                                               _init@resource:///org/gnome/shell/ui/workspace.js:160:14
                                               _addWindowClone@resource:///org/gnome/shell/ui/workspace.js:1856:21
                                               _init@resource:///org/gnome/shell/ui/workspace.js:1174:22
                                               _updateWorkspaces@resource:///org/gnome/shell/ui/workspacesView.js:231:29
                                               _init@resource:///org/gnome/shell/ui/workspacesView.js:90:14
                                               _updateWorkspacesViews@resource:///org/gnome/shell/ui/workspacesView.js:681:24
                                               show@resource:///org/gnome/shell/ui/workspacesView.js:611:14
                                               show@resource:///org/gnome/shell/ui/viewSelector.js:276:33
                                               _animateVisible@resource:///org/gnome/shell/ui/overview.js:579:27
                                               show@resource:///org/gnome/shell/ui/overview.js:565:14
                                               toggle@resource:///org/gnome/shell/ui/overview.js:688:18
                                               _initializeUI/<@resource:///org/gnome/shell/ui/main.js:223:22
avril 30 14:27:32 tistus-PC systemd-resolved[961]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

En mettant Networkmanager comme élément d'entrée, tu devrais être assez bien. Par la suite, ceux qui vont étudier le problème sauront ré-aiguiller.

As-tu pensé à ces commandes

sudo apt update
sudo apt upgrade

Dernière modification par geole (Le 30/04/2020, à 18:40)

MJ_Tistus · Le 30/04/2020, à 18:46

D'accord, je vais tenter ça.
Pour le reste que dois-je relayer en priorité ? je suppose que je ne peux pas inclure tous les résultats de commandes dans un tel bug report, ça ferai beaucoup

EDIT :

geole a écrit :

As-tu pensé à ces commandes
sudo apt update
sudo apt upgrade

non, j'avoue que je n'ai pas pensé à faire les majs depuis ce bug. je viens de le faire, je vais regarder si ça arrête de mettre les mêmes alertes.

Dernière modification par MJ_Tistus (Le 30/04/2020, à 18:53)

geole · Le 30/04/2020, à 19:03

Pour avoir une idée tu peux regarder ce bug https://bugs.launchpad.net/ubuntu/+sour … ug/1875647
Je l'avais ouvert avec seulement le message " freewifi and IPAD not détected in 20.04.0" Depuis il a été complété par ceux qui traitent le problème

Mais la seconde commande a collecté pleins de fichiers.

Tu pourras te permettre de transférer les 5000 dernières lignes du journal
1) extraire

sudo  journalctl -n5000 >TraceJournal.txt

2) Te connecter à ton bug et ajouter un commentaire en joignant le fichier.

Dernière modification par geole (Le 30/04/2020, à 19:10)

MJ_Tistus · Le 30/04/2020, à 19:14

tiens ! du nouveau de la commande journalctl --no-pager -n200

avril 30 19:02:32 tistus-PC systemd-resolved[961]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
avril 30 19:03:01 tistus-PC kernel: TCP: enp6s0: Driver has suspect GRO implementation, TCP performance may be compromised.

mais en même temps il écrit tellement de trucs depuis tout à l'heure que j'ai sûrement loupé plein de choses importantes.

geole a écrit :

Tu pourras te permettre de transférer les 5000 dernières ligne du journal
1) extraire
sudo  journalctl -n5000 >TraceJournal.txt
2) Te connecter à ton bug et ajouter un commentaire en joignant le fichier.

d'accord, je vais tenter ça. Ça va sûrement me prendre un moment cette histoire de report ça proprement donc je ne sais pas quand j'aurai fini. Mais dès que c'est bon je vous met le lien.
Si vous avez d'autres conseils ou questions je garde un œil dessus cette page.

xubu1957 · Le 30/04/2020, à 19:23

En regardant > TCP: eth0: Driver has suspect GRO implementation, TCP performance may be compromised.

Montre :

lspci -k -nn | grep -A 3 -i net

MJ_Tistus · Le 30/04/2020, à 20:13

Pardon, je rédigeais le bug report...

lspci -k -nn | grep -A 3 -i net

06:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03)
	Subsystem: Gigabyte Technology Co., Ltd I211 Gigabit Network Connection [1458:e000]
	Kernel driver in use: igb
	Kernel modules: igb
08:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1143 USB 3.1 Host Controller [1b21:1343]

MJ_Tistus · Le 01/05/2020, à 00:26

Voici le lien du bug report :
https://bugs.launchpad.net/ubuntu/+sour … ug/1876195

MJ_Tistus · Le 01/05/2020, à 12:48

Je vais sans doute tenter les différents conseils de la page Ubuntu SSD , c'est interressant et ça me permettra de ménager mon SSD si ce genre de choses viennent à se reproduire.
Mais avant cela mon dossier /var fait toujours une taille de 7,1 Go, dont 4,5 de log et 2,6 de lib. C'est moins grave qu'un syslog de 50Go mais ça reste bien encombrant.
Avez vous des conseils pour réduire cette masse ?
Si j'ai bien compris les journaux systèmes sont copiés trois fois : dans syslog, dans kernel et dans journal.
Du coup j'aimerai savoir ce que je peux supprimer et les paramètres que je peux changer (s'il y en a d'autres que ce que @geole m'a montré) pour retrouver une taille normale de /var, du genre pas plus de quelques centaines de Mo max comme c'est d'habitude il me semble ?
Et avant ça, est-ce qu'il y a un moyen d'analyser plus en profondeur les journaux toujours présent, pour trouver le log le plus fréquemment produit (du genre une commande qui trouverai la ligne la plus répétée si on ignore la date) ou pour remonter au 28/29 avril pour regarder au moment ou 50Go de logs ont étés produit pour voir ce qu'il se passait ?

geole · Le 01/05/2020, à 13:19

Bonjour
Pour le journal, en version 20.04, je n'ai pas encore vérifié si le principe est différent. Il peut exister une commande plus simple qui fonctionne pour éviter le déversement vers les logs. Mais le principe de la collecte est certainement resté le même. Collecter jusqu'à utilisation de 10% de l'espace disque de la partition avec un maxima de 4 Go.

Tu peux cependant, faire des épurations régulières pour ne conserver que quelques jours, qu'un an, qu'une semaine, que N jours
A tire d'exemple

####épuration du journal  ===> voir sudo gedit /etc/systemd/journald.conf
sudo journalctl --vacuum-size=1G  --vacuum-time=10d –vacuum-files=50
ou
sudo journalctl   --vacuum-time=2d

Pour lister les grosses erreurs rencontrées depuis le début ou le début de la session

journalctl --no-pager -p err
ou 
journalctl --no-pager  -b -p err

Pour rechercher des choses particulières en paramétrant bien

journalctl    --no-pager --since  "2017-12-06 00:25" --until  "2017-12-06 01:00" >Trace.txt && cat Trace.txt

Pour rechercher la mise en route

journalctl  -b-1  | sed -n '/random: crng/,/Startup finished in/p'

Pour utiliser au mieux la RAM et ne déclencher le swap que tardivement paragraphe 3.1.2 de https://doc.ubuntu-fr.org/swap#ameliore … hange_swap

Pour mettre le répertoire /tmp en mémoire paragraphe 3.1 de https://doc.ubuntu-fr.org/tmpfs
La taille à mettre dépend de la taille RAM disponible, avec 100 Mo on a déjà pas mal.

Dernière modification par geole (Le 01/05/2020, à 13:25)

geole · Le 01/05/2020, à 13:33

geole a écrit :

Bonjour
Pour le journal, en version 20.04, je n'ai pas encore vérifié si le principe est différent. Il peut exister une commande plus simple qui fonctionne pour éviter le déversement vers les logs. Mais le principe de la collecte est certainement resté le même. Collecter jusqu'à utilisation de 10% de l'espace disque de la partition avec un maxima de 4 Go.
Je sais qu'il existe une option pour ne pas du tout produire les traces sur disque dur. Il ne faut la valider que lorsque ubuntu fonctionne bien.
Tu peux cependant, faire des épurations régulières pour ne conserver que quelques jours, qu'un an, qu'une semaine, que N jours
A tire d'exemple
####épuration du journal  ===> voir sudo gedit /etc/systemd/journald.conf
sudo journalctl --vacuum-size=1G  --vacuum-time=10d –vacuum-files=50
ou
sudo journalctl   --vacuum-time=2d 
Pour lister les grosses erreurs rencontrées depuis le début ou le début de la session
journalctl --no-pager -p err
ou 
journalctl --no-pager  -b -p err
Pour rechercher des choses particulières en paramétrant bien
journalctl    --no-pager --since  "2017-12-06 00:25" --until  "2017-12-06 01:00" >Trace.txt && cat Trace.txt
Pour rechercher la mise en route
journalctl  -b-1  | sed -n '/random: crng/,/Startup finished in/p'
Pour utiliser au mieux la RAM et ne déclencher le swap que tardivement paragraphe 3.1.2 de https://doc.ubuntu-fr.org/swap#ameliore … hange_swap
Pour mettre le répertoire /tmp en mémoire paragraphe 3.1 de https://doc.ubuntu-fr.org/tmpfs
La taille à mettre dépend de la taille RAM disponible, avec 100 Mo on a déjà pas mal.

Il faut éviter de "Cacher des mises à jour et paquets téléchargés" sauf peut-être si on a un excellant réseau capable de les récupérer très rapidement à chaque démarrage. Il me semble que le ZRAM peut réserver des surprises.

Dernière modification par geole (Le 01/05/2020, à 13:34)

MJ_Tistus · Le 01/05/2020, à 14:36

Alors : le résultat de la commande

journalctl --no-pager -p err

avril 29 23:20:14 tistus-PC rsyslogd[1037]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 23:20:14 tistus-PC rsyslogd[1037]: action 'action-2-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2001.0 try https://www.rsyslog.com/e/2027 ]

et cela plusieurs centaines de fois, tellement que le terminal n'affiche pas le début de la commande, donc je ne remonte pas plus haut.
Jusqu'à mon redémarrage qui ne marche pas, puis le redémarrage qui marche quand j'ai compris qu'il fallait que je libère de la place :

avril 29 23:21:16 tistus-PC rsyslogd[1037]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 23:21:16 tistus-PC rsyslogd[1037]: action 'action-2-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 23:21:16 tistus-PC rsyslogd[1037]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
-- Reboot --
avril 29 23:22:27 tistus-PC kernel: Initramfs unpacking failed: Decoding failed
-- Reboot --
avril 29 23:37:34 tistus-PC kernel: Initramfs unpacking failed: Decoding failed
avril 29 23:37:59 tistus-PC gdm-password][1710]: gkr-pam: unable to locate daemon control file
avril 29 23:38:05 tistus-PC pulseaudio[1765]: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
avril 30 00:47:20 tistus-PC pulseaudio[1765]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
avril 30 00:47:20 tistus-PC pulseaudio[1765]: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
avril 30 00:47:20 tistus-PC pulseaudio[1765]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x40:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x7:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 10:37:01 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f09
avril 30 11:03:05 tistus-PC pulseaudio[10839]: Failed to acquire org.PulseAudio1: org.freedesktop.DBus.Error.Disconnected: Connection is closed
-- Reboot --
avril 30 11:03:35 tistus-PC kernel: Initramfs unpacking failed: Decoding failed
-- Reboot --
avril 30 11:12:32 tistus-PC kernel: Initramfs unpacking failed: Decoding failed
avril 30 11:12:50 tistus-PC gdm-password][1706]: gkr-pam: unable to locate daemon control file
avril 30 11:13:03 tistus-PC pulseaudio[1745]: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x1:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0xa:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x70:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x1:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f0a
avril 30 12:59:48 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f0a
avril 30 13:02:04 tistus-PC pulseaudio[1745]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
avril 30 13:02:04 tistus-PC pulseaudio[1745]: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
avril 30 13:02:04 tistus-PC pulseaudio[1745]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f12
avril 30 13:33:51 tistus-PC gdm3[1171]: GLib: Source ID 67 was not found when attempting to remove it
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
mai 01 12:04:10 tistus-PC gdm3[1171]: GLib: Source ID 68 was not found when attempting to remove it
mai 01 12:04:15 tistus-PC systemd[1]: Failed to start Refresh fwupd metadata and update motd.
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f10
mai 01 13:56:28 tistus-PC gdm3[1171]: GLib: Source ID 69 was not found when attempting to remove it

Je ne sais pas ce que ces lignes signifient dans le détail mais je me demande si le problème n'a pas pour origine mon système audio, et donc l'installation de discord...
Ce qui expliquerai que le problème ne se soit pas reproduit : je n'ai pas redémarré discord depuis le bug.
Ou une alliance problème Discord - problème internet. Le premier ayant besoin du second, si internet marchait mal cela a peut-être rendu discord susceptible.
Je continue d'investiguer là dessus avec les commandes que tu m'a donné.

EDIT :
J'ai réussi à récupérer le début dans un fichier :

-- Logs begin at Wed 2020-04-29 00:34:48 CEST, end at Fri 2020-05-01 14:38:47 CEST. --
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x80000000:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x0:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC kernel: snd_hda_intel 0000:09:00.1: spurious response 0x1:0x0, last cmd=0x5f2f08
avril 29 19:12:41 tistus-PC gdm3[1189]: GLib: Source ID 67 was not found when attempting to remove it
avril 29 20:04:49 tistus-PC rsyslogd[1048]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]: action 'action-2-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]: action 'action-2-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]: action 'action-2-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]
avril 29 20:04:49 tistus-PC rsyslogd[1048]:  message repeated 4 times: [file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try https://www.rsyslog.com/e/2027 ]]

Ceci :

avril 29 19:12:41 tistus-PC gdm3[1189]: GLib: Source ID 67 was not found when attempting to remove it

se produit juste avant l'emballement j'ai l'impression. Vous avez une idée de ce que ça peut-être ?
Ou alors une idée à propos du problème audio ?

Dernière modification par MJ_Tistus (Le 01/05/2020, à 14:48)

MJ_Tistus · Le 02/05/2020, à 19:03

Je vais maintenant laisser ce bug aux devs.
Dernière chose à ce lien :
https://doc.ubuntu-fr.org/ssd_solid_sta … _mecanique
il est dit qu'on peut placer les logs/fichiers temporaires sur le HDD si on a un Disque dur en plus du SDD, ce qui permet à la fois d'éviter l'usure du SSD et de faire face au bug que j'ai eu (si les logs avaient étés sur mon HDD ils auraient mis plus de temps à saturer ses 3 To et en prime s'ils y étaient parvenus ils ne m'auraient tout de même pas empêcher de démarrer).
Seulement l'auteur du tuto n'a pas développé cette solution, préférant la solution en mémoire vive. Avez vous des conseils pour mettre ça en place ? Comment déplacer /var voire /tmp sur le HDD ?

moko138 · Le 03/05/2020, à 03:41

Bonjour,
Oui, puisque la cause n'a pas été éliminée, déplacer sur le HDD /var/log (et non tout /var, ce qui ralentirait fort ton système, et inutilement) évitera d'user prématurément le SSD.
C'est à faire en session live, sans oublier de modifier le fichier /etc/fstab.

(Par contre, il est inutile de déplacer /tmp, c'est une idée reçue que beaucoup répètent sans réfléchir mais elle est fausse).

Mais il faut d'abord faire deux choses :

1) Alléger momentanément /var/log
Tu vérifieras d'abord si le fichier le plus lourd est syslog ou syslog.1 :

ls -lSh /var/log | head -4

et tu adapteras (si besoin) le nom du fichier (en trois endroits) dans la commande du deuxième message (que tu avais déjà appliquée).
Et si le fichier le plus lourd est un syslog* compressé (extension .gz), tu appliqueras cette variante-ci

cd /var/log && echo "Avant : $(sudo du -sh)" && echo | sudo tee syslog.2.gz && echo "Après : $(sudo du -sh)"

(là encore, tu adapteras le chiffre, si besoin).
/!\ Mais ne supprime plus de fichier log !

Et la deuxième action :

2) Limiter définitivement le poids total de /var/log
J'ai tout indiqué dans ce message : ./viewtopic.php?pid=22191055#p22191055
Lis-le attentivement et entièrement avant de passer à l'action ou de me poser (ici) tes questions.

= =

Après quoi, tu annuleras la manip' que tu avais faite entre #22 et #23, puisque son rapport avantages/inconvénients se sera inversé (du fait de la deuxième action, ci-dessus)..

MJ_Tistus · Le 03/05/2020, à 16:18

moko138 a écrit :

Oui, puisque la cause n'a pas été éliminée, déplacer sur le HDD /var/log (et non tout /var, ce qui ralentirait fort ton système, et inutilement) évitera d'user prématurément le SSD.

d'accord, merci pour l'info.
Par curiosité à quoi sert /var à part aux logs ?

moko138 a écrit :

C'est à faire en session live, sans oublier de modifier le fichier /etc/fstab.

À chaque installation d'Ubuntu je fais une manipulation dans l'application disques afin de monter une partition ext4 de mon HDD sur /data/LinuxData à chaque démarrage et j'utilise un script pour déplacer vers le HDD les dossiers "classiques" (Téléchargements, Images,...) afin de stocker la masse des données sur le HDD tout en gardant les dossiers cachés d'application sur le SSD afin de lancer les logiciels plus vite. Ça modifie le fstab normalement, je suppose que ça suffit.
Je voulais utiliser ce script :

#!/bin/bash
UTILISATEUR=tistus     #### Nom de l’utilisateur de DATA  au cas où il ne serait pas identique à $USER
i=var
#for i  in  var
#do
   echo "Début de traitement de  $i "
   mkdir   /data/LinuxData/$UTILISATEUR/racine/$i
   mv -nv /$i/* /data/LinuxData/$UTILISATEUR/racine/$i
   rm -Rv /$i
   ln -sd /data/LinuxData/$UTILISATEUR/racine/$i /$i
   ls -ls /$i
#   done

élaboré à partir de mon script habituel pour le /home/user
Je vais donc suivre ton conseil et remplacer /var par /var/log

J'ai refais une installation propre pour m'épargner certains problèmes (oui et au passage j'avais entièrement cassé /var au cour de certains tests donc c'était mieux pour le système)

moko138 a écrit :

2) Limiter définitivement le poids total de /var/log
J'ai tout indiqué dans ce message : ./viewtopic.php?pid=22191055#p22191055 smile
Lis-le attentivement et entièrement avant de passer à l'action ou de me poser (ici) tes questions.

Je vais faire ça.

moko138 a écrit :

Après quoi, tu annuleras la manip' que tu avais faite entre #22 et #23, puisque son rapport avantages/inconvénients se sera inversé (du fait de la deuxième action, ci-dessus)..

Pourquoi ? Ne peut-on pas garder seulement la journalisation journalctl (qui de ce que j'ai vu est plus récente et pose moins de problèmes) ET limiter la taille de var/log afin d'éviter que même ce système de journalisation ne s'alourdisse trop ?

Dernière modification par MJ_Tistus (Le 03/05/2020, à 16:19)

moko138 · Le 04/05/2020, à 04:35

MJ_Tistus a écrit :

(...)
moko138 a écrit :
2) Limiter définitivement le poids total de /var/log
J'ai tout indiqué dans ce message : ./viewtopic.php?pid=22191055#p22191055 smile
Lis-le attentivement et entièrement avant de passer à l'action ou de me poser (ici) tes questions.
Je vais faire ça.
moko138 a écrit :
Après quoi, tu annuleras la manip' que tu avais faite entre #22 et #23, puisque son rapport avantages/inconvénients se sera inversé (du fait de la deuxième action, ci-dessus).
Pourquoi ? Ne peut-on pas garder seulement la journalisation journalctl (qui de ce que j'ai vu est plus récente et pose moins de problèmes) ET limiter la taille de var/log afin d'éviter que même ce système de journalisation ne s'alourdisse trop ?

C'est faisable. À l'extrême, il y a même eu la mode de mettre les logs en RAM, avec pour conséquence qu'après un plantage (moment où les logs sont des plus utiles) les logs ne sont pas consultables puisqu'ils n'existent plus...

Mais si tu considères que les logs sont utiles,
et que tu as réglé le problème du poids de /var/log,
pourquoi continuer d'en éliminer cron.log et daemon.log ?

Je vois ta logique : tu postules que le contenu de tous les fichiers .log* est dupliqué dans le journal - c'est peut-être vrai, je n'en sais rien - et que tu sauras y retrouver sélectivement l'info dont tu auras besoin.
Mais alors, si on suit ta logique jusqu'au bout, tu devrais éliminer tout /var/log/* sauf /var/log/journal.
Et là, mon petit doigt me dit qu'on se retrouve dans l'expérimental...

= =

Quant à ton affirmation

la journalisation journalctl (...) pose moins de problèmes

je ne la tiens pas pour exacte : dans ton cas, c'est syslog qui croissait exagérément, mais dans d'autres cas vus sur le forum, c'était le journal.
D'où l'intérêt du lien que je t'ai donné plus haut et qui règle les deux, et tout /var/log.

moko138 · Le 04/05/2020, à 06:51

Sur les façons de mettre /var/log sur un autre disque, tu peux t'inspirer de ce message ./viewtopic.php?pid=21993003#p21993003 que je viens de mettre à jour.

MJ_Tistus · Le 13/05/2020, à 01:02

J'ai du coup rajouté

/var/log/ /data/LinuxData/tistus/var/log max_dir_size_kb=6291456

en bas de mon /etc/fstab

# /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>
# / was on /dev/sda6 during installation
UUID=6917f051-a8a0-4bd7-bbe9-f248556690c1 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=3CAD-6FC0  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
/dev/disk/by-uuid/2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData auto nosuid,nodev,nofail,x-gvfs-show 0 0
/var/log/ /data/LinuxData/tistus/var/log max_dir_size_kb=6291456

Est-ce suffisant pour déplacer définitivement le dossier /var/log dans /data/LinuxData/tistus/var/log ?

Ou ma solution antérieure à base de liens est meilleure ?
je précise que je ne l'avais pas encore appliquée, j'ai fait une pause avec l’ordinateur quelques jours, d'ailleurs je n'avais pas vu la réponse.

Dernière modification par MJ_Tistus (Le 13/05/2020, à 01:06)

geole · Le 13/05/2020, à 09:40

Bonjour.
Après pas mal de réflexions, je trouve totalement stupide de conserver les logs une "éternité", alors que chaque "seconde" qui passe fabrique une trace du problème. Il suffit de consulter dans la session en cours.
Voici donc une nouvelle recommandation que j'ai "pondu" récemment.
1) Avec un éditeur de texte, ouvrir le fichier /etc/systemd/journald.conf (Ne pas oublier de le sauver en cas de fausse manipulation.)
et y ajouter cette ligne
Storage=volatile
derrière la ligne
#Storage=auto

NOTA: La ligne ne commence pas par un # afin d'être prise en compte.

man journald.conf a écrit :

If "volatile", journal log data
will be stored only in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed).

Dernière modification par geole (Le 13/05/2020, à 09:42)

MJ_Tistus · Le 13/05/2020, à 11:43

geole a écrit :

Bonjour.
Après pas mal de réflexions, je trouve totalement stupide de conserver les logs une "éternité", alors que chaque "seconde" qui passe fabrique une trace du problème. Il suffit de consulter dans la session en cours.
Voici donc une nouvelle recommandation que j'ai "pondu" récemment.
1) Avec un éditeur de texte, ouvrir le fichier /etc/systemd/journald.conf (Ne pas oublier de le sauver en cas de fausse manipulation.)
et y ajouter cette ligne
Storage=volatile
derrière la ligne
#Storage=auto
NOTA: La ligne ne commence pas par un # afin d'être prise en compte.
man journald.conf a écrit :
If "volatile", journal log data
will be stored only in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed).

Je préfère en garder une trace, ce problème n'est pas le seul susceptible d'arriver à mon ordinateur et je veux pouvoir consulter les logs si je suis obligé de reboot à cause d'un crash.
Surtout que pour l'instant le problème n'existe pas sur cette nouvelle installation.

J'ai cru comprendre au post de moko qu'on peut modifier l'emplacement de /var/log juste dans le fstab, ce qui serai sans doute préférable à ma méthode script avec des liens, que je trouve un peu bourrine.
Avec un déplacement sur le HDD et une mémoire de 6go je ne devrai de toute manière plus avoir de problèmes.
Le truc c'est que j'ai l'impression que la ligne dont je parle dans mon message précédent ne fais rien... Les journaux restent dans /var/log et pas dans le dossier sur HDD

geole · Le 13/05/2020, à 12:26

MJ_Tistus a écrit :

# /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>
# / was on /dev/sda6 during installation
UUID=6917f051-a8a0-4bd7-bbe9-f248556690c1 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=3CAD-6FC0  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
/dev/disk/by-uuid/2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData auto nosuid,nodev,nofail,x-gvfs-show 0 0
/var/log/ /data/LinuxData/tistus/var/log max_dir_size_kb=6291456

Est-ce suffisant pour déplacer définitivement le dossier /var/log dans /data/LinuxData/tistus/var/log ?

Je n'ai plus d'exemple personnel sur cette technique de montage.
Mais je serais plutôt tenté d'écrire
### Montage de la partition qui va contenir les logs en technique classique après avoir remplacé les XXXXX grâce à la commande sudo blkid
UUID=2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxDat ext4 defaults 0 1
#####Mise d'un point de montage grâce à la technique de lien.
/data/LinuxData/tistus/var/log /var/log none bind 0 0

Donc, sans certitude sur la bonne codification
/data/LinuxData/tistus/var/log /var/log none bind max_dir_size_kb=6291456 0 0

Pour contrôler, tu feras

 ls -ls /data/LinuxData/tistus/var/log

Je ne connais pas trop la technique de limite de taille, Je vais essayer de regarder la codification.
Nota. Je suis désolé de ne pas avoir réussi à te convaincre qu'il est plus pertinent de regarder les incidents du jour plutôt que ceux de l'an dernier. .

Dernière modification par geole (Le 13/05/2020, à 12:45)

MJ_Tistus · Le 13/05/2020, à 15:16

geole a écrit :

Nota. Je suis désolé de ne pas avoir réussi à te convaincre qu'il est plus pertinent de regarder les incidents du jour plutôt que ceux de l'an dernier. .

Ne le prends pas mal, d'autant qu'on s'est peut-être mal compris.

Si j'ai bien compris ta méthode à chaque fin de session (donc à chaque redémarrage) les logs sont supprimés. (préviens moi si c'est une erreur d'interprétation)
Or à chaque fois que j'ai un bug, je ne cherche pas, je redémarre, tu remarquera d’ailleurs que c'est par ça que commence ce post XD
Si je constate à l'issue du redémarrage que ça recommence ou que mon système fait des choses bizarres, je cherche alors à comprendre. Du coup si les logs disparaissent à chaque redémarrage je n'ai aucune manière d'en savoir plus sur ce qui a mis mon ordinateur dans cet état. C'est pour ça que je cherche à en garder un minimum.

geole a écrit :

Après pas mal de réflexions, je trouve totalement stupide de conserver les logs une "éternité", alors que chaque "seconde" qui passe fabrique une trace du problème.

Là aussi j'ai peur qu'on se comprenne mal, j'ai réinstallé Ubuntu, le bug qui a provoqué tout cela ne semble pas se représenter. Maintenant je cherche à assurer mes arrières, je sais que ça peut se produire, je sais que ça peut aller jusqu'à m'empêcher de démarrer, je sais que ça use le SSD... donc je veux le déplacer à un endroit où il ne fera pas de dégâts mais où je pourrais regarder ce qu'il se passe en cas de problème.

Donc je pense que le mieux serai de le mettre sur la partition HDD déjà faite, dans un dossier limité en taille (bien que dans le pire des cas je pourrait quand même redémarrer et supprimer manuellement vu que ce n'est pas sur la partition système), et de préférence si vous savez comment faire en demandant au système de journalisation de supprimer les anciens logs en premier en cas de trop plein.

Je me base sur ce que vous m'avez tous appris et sur ce que je sais de la situation actuelle de mon ordi pour tenter de déterminer ce dont j'ai besoin. Je sais que vous êtes plus expérimentés et je ne veux pas paraître ingrat, c'est juste qu'avec toutes les solutions présentées j'ai pensé que pour le futur débogage du système et vu que mes logs font 200 Mo, déplacer vers le HDD est le meilleur compromis.

Je vous remercie d'ailleurs tous énormément pour votre aide et pour ce que vous m'avez appris, qui j'en suis certain me servira lors du prochain bug. (Les logs j'y connaissait rien avant, ce que j'en sais je vous le dois)

geole · Le 13/05/2020, à 17:43

Il n'y a pas de raison que je le prenne mal.
Il y a pas mal de temps que j'ai compris que les logs étaient très utiles à condition de les comprendre.
Certaines traces aident, mais dans certains cas, on n'y trouve rien. Spécialement lors d'un plantage de l'ordinateur ou d'un arrêt qui se passe mal. C'est pour cela que je commence à penser que la trace de la session en cours est bien suffisante. En cas de problème rencontré, on pourra toujours demander d'activer l'historisation de la collecte pour le prochain ennui.
En revanche, collecter en double exemplaire n'est pas une chose normale, même si c'est sur un disque dur.

J'essaie de t'aider à trouver la bonne codification pour stocker sur le disque dur au lieu du SSD. Lorsqu'un ordinateur fonctionne bien, il semble inutile de limiter la collecte.. Je t'ai montré que tu avais inversé l'ordre de la liaison en te proposant la bonne codification de la ligne . Mais je n'ai pas trouvé d'exemple de limitation d'espace avec ce montage.
Je ne sais d'ailleurs pas ce qui va se passer lorsque la limite sera atteinte. Cela serait bien tu racontes.

Je ne connais pas plus trop les problèmes que tu as actuellement . Tu serais obligé régulièrement d'appuyer sur la touche d'arrêt marche car tu as totalement perdu la main au clavier? Dans ce contexte, il faut effectivement ne pas conserver en volatif pour traiter au reboot le problème.
Mais il doit bien exister un certain nombre d'ordinateurs qui fonctionnent et certains cas de perte de main dont on connaît la cause.

Que donne la commande

 journalctl  -b  -p err

Certaines erreurs sont "normales"

Normalement le systemd de log est basé sur le fait de ne pas dépasser 4 Go ou 10% de la partition racine si elle est plus petite que 40 Go
A cela, il faut ajouter les doublons (inutiles) des syslog et kern.log qui ont leur propre gestion.
Pour descendre plus bas, il faut penser à lancer régulièrement une commande d'épuration de ce style

sudo journalctl --vacuum-size=1G  --vacuum-time=7d –vacuum-files=10

man journalctl ==>
       --vacuum-size=, --vacuum-time=, --vacuum-files=
           Removes archived journal files until the disk space they use falls
           below the specified size (specified with the usual "K", "M", "G"
           and "T" suffixes), or all archived journal files contain no data
           older than the specified timespan (specified with the usual "s",
           "m", "h", "days", "months", "weeks" and "years" suffixes), or no
           more than the specified number of separate journal files remain.
           Note that running --vacuum-size= has only an indirect effect on the
           output shown by --disk-usage, as the latter includes active journal
           files, while the vacuuming operation only operates on archived
           journal files. Similarly, --vacuum-files= might not actually reduce
           the number of journal files to below the specified number, as it
           will not remove active journal files.  --vacuum-size=,
           --vacuum-time= and --vacuum-files= may be combined in a single
           invocation to enforce any combination of a size, a time and a
           number of files limit on the archived journal files. Specifying any
           of these three parameters as zero is equivalent to not enforcing
           the specific limit, and is thus redundant.

MJ_Tistus · Le 13/05/2020, à 18:46

geole a écrit :

Je ne connais pas plus trop les problèmes que tu as actuellement . Tu serais obligé régulièrement d'appuyer sur la touche d'arrêt marche car tu as totalement perdu la main au clavier? Dans ce contexte, il faut effectivement ne pas conserver en volatif pour traiter au reboot le problème.

rien de spécial pour l'instant, mais comme dès que j'ai un problème je redémarre, je préfère ne pas erase à chaque fin de session. Je sais que le jour où j'ai quoi que ce soit je le fait.

j'ai fait plusieurs tests pour tenter de déplacer /var/log avec la méthode de moko138 mais je pense que je n'ai pas du tout saisir, ça ne marche pas. Je vais tenter de remplacer ça par ta solution.

Du coup la ligne :

/data/LinuxData/tistus/var/log    /var/log none  bind  max_dir_size_kb=6291456   0    0

fonctionne, merci beaucoup !

ls -ls /data/LinuxData/tistus/var/log

total 736
  4 -rw-r----- 1 syslog adm    3764 mai   13 18:28 auth.log
 12 -rw------- 1 root   root  10805 mai   13 18:27 boot.log
  0 -rw-rw---- 1 root   utmp      0 mai   13 18:27 btmp
  4 drwxr-x--- 2 root   lp     4096 mai   13 18:27 cups
 96 -rw-r--r-- 1 root   adm   96277 mai   13 18:27 dmesg
  4 drwx--x--x 2 root   gdm    4096 mai   13 18:27 gdm3
  4 -rw-r--r-- 1 root   root   1189 mai   13 18:27 gpu-manager.log
128 -rw-r----- 1 syslog adm  128251 mai   13 18:28 kern.log
  0 -rw-rw-r-- 1 root   utmp      0 mai   13 18:27 lastlog
  4 drwx------ 2 root   root   4096 mai   13 18:27 private
392 -rw-r----- 1 syslog adm  399914 mai   13 18:28 syslog
  4 drwxr-xr-x 2 root   root   4096 mai   13 18:27 unattended-upgrades
  4 -rw-rw-r-- 1 root   utmp   1152 mai   13 18:27 wtmp
 40 -rw-r--r-- 1 root   root  38867 mai   13 18:27 Xorg.0.log
 40 -rw-r--r-- 1 root   root  39267 mai   13 18:27 Xorg.1.log

Voilà, ça marche.
J'espère que l'option limitant à 6 go fonctionne, mais je suppose que oui.

Tu m'a fait remarquer plusieurs fois que les trois journaux systèmes différents étaient inutilement redondants, et là dessus je pense que tu as raison. Celui qui m'embête le plus c'est syslog. journalctl est limité, ce que je trouve relativement normal, je suis encore ahuri qu'aucun dev n'ai limité la taille du fichier syslog... bref
Tu me conseille de réitérer ta manœuvre consistant à commenter deux lignes de /etc/rsyslog.d/50-default.conf afin d'arrêter les journalisations syslog et kernel ou d'attendre voir si ça ne marche pas tout seul sans problème ? Et si je commente, est-ce que je ne commente que syslog qui a provoqué tout ce foutoir ou kernel également ?

/var/log contient toujours quelques fichiers, mais 730 ko, et non plus les 200Mo qu'il contenait il y a 5m. Est-ce que je dois les supprimer ou ce sont des fichiers persistant qui restent là et que je ne dois pas toucher ?

Merci en tous cas

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 30/04/2020, à 17:37

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#27 Le 30/04/2020, à 18:15

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#28 Le 30/04/2020, à 18:23

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#29 Le 30/04/2020, à 18:46

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#30 Le 30/04/2020, à 19:03

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#31 Le 30/04/2020, à 19:14

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#32 Le 30/04/2020, à 19:23

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#33 Le 30/04/2020, à 20:13

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#34 Le 01/05/2020, à 00:26

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#35 Le 01/05/2020, à 12:48

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#36 Le 01/05/2020, à 13:19

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#37 Le 01/05/2020, à 13:33

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#38 Le 01/05/2020, à 14:36

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#39 Le 02/05/2020, à 19:03

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#40 Le 03/05/2020, à 03:41

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#41 Le 03/05/2020, à 16:18

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#42 Le 04/05/2020, à 04:35

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#43 Le 04/05/2020, à 06:51

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#44 Le 13/05/2020, à 01:02

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#45 Le 13/05/2020, à 09:40

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#46 Le 13/05/2020, à 11:43

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#47 Le 13/05/2020, à 12:26

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#48 Le 13/05/2020, à 15:16

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#49 Le 13/05/2020, à 17:43

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

#50 Le 13/05/2020, à 18:46

Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go

Pied de page des forums