#51 Le 13/05/2020, à 18:52
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
ls -ls /var/log
total 744
4 -rw-r----- 1 syslog adm 3957 mai 13 18:30 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
400 -rw-r----- 1 syslog adm 409012 mai 13 18:51 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.logce qu'il reste dans /var/log
Hors ligne
#52 Le 13/05/2020, à 19:09
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Il y a quelques chose de pas clair dans ce répertoire.
J'aurais aimé y trouver les deux répertoires qui assurent la vraie collecte
4 drwxr-sr-x+ 3 root systemd-journal 4096 janv. 26 12:00 journal
4 drwxr-xr-x 2 root root 4096 janv. 8 13:02 journal MAIS Vu leur position stratégique, il est possible qu'ils soient activés avant que le montage de la partition de substitution soit effectuée.
De la recherche dans internet à faire!!
====> premier ajout Voir réponse 2 de ce document https://unix.stackexchange.com/question … other-than
Donc effectivement il faut une technique particulière ... dont je comprends mal la mise en oeuvre
===> je vais essayer de vérifier cette réponse
Par conséquent, il est possible et sûr de stocker le journal dans un autre emplacement. Vous avez juste besoin d'ajouter / changer
Storage=/some-filesystem-with-free-space/some-dir/
dans l' un des fichiers de configuration de journald .
Tu sais ce que je pense de la présence de ces deux fichiers
128 -rw-r----- 1 syslog adm 128251 mai 13 18:28 kern.log
400 -rw-r----- 1 syslog adm 409012 mai 13 18:51 syslogNOTA. Je n'avais pas vu que tu avais fait deux réponses.
==>Regarde cette discussion https://forum.ubuntu-fr.org/viewtopic.php?id=2052486 Il n'est pas évident de trouver la cause même avec un historique.
==> Ainsi que celle-ci https://forum.ubuntu-fr.org/viewtopic.php?id=2052838
Qui démontrent que je change d'avis sur le besoin de conserver préventivement les traces des log.
Dernière modification par geole (Le 14/05/2020, à 13:11)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#53 Le 14/05/2020, à 19:16
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
nouveau test et les deux dossiers dont tu parle ne semblent toujours pas présents
en plus les logs sont présents dans /data/LinuxData/tistus/var/log mais ils sont aussi présent dans /var/log donc l'intérêt est limité.
ls -ls /var/log
total 1664
16 -rw-r----- 1 syslog adm 13124 mai 14 19:06 auth.log
12 -rw------- 1 root root 10729 mai 14 19:05 boot.log
12 -rw------- 1 root root 10805 mai 14 14:07 boot.log.1
0 -rw-rw---- 1 root utmp 0 mai 13 18:27 btmp
4 drwxr-x--- 2 root lp 4096 mai 14 14:07 cups
96 -rw-r--r-- 1 root adm 96496 mai 14 19:05 dmesg
96 -rw-r--r-- 1 root adm 96277 mai 13 18:27 dmesg.0
4 drwx--x--x 2 root gdm 4096 mai 13 18:27 gdm3
4 -rw-r--r-- 1 root root 1189 mai 14 19:05 gpu-manager.log
4 -rw-r--r-- 1 root root 1196 mai 14 19:05 gpu-manager-switch.log
284 -rw-r----- 1 syslog adm 287237 mai 14 19:06 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
516 -rw-r----- 1 syslog adm 521040 mai 14 19:06 syslog
428 -rw-r----- 1 syslog adm 435472 mai 14 14:07 syslog.1
4 drwxr-xr-x 2 root root 4096 mai 14 14:07 unattended-upgrades
4 -rw-rw-r-- 1 root utmp 2688 mai 14 19:06 wtmp
40 -rw-r--r-- 1 root root 38867 mai 14 19:06 Xorg.0.log
40 -rw-r--r-- 1 root root 40445 mai 14 19:05 Xorg.0.log.old
40 -rw-r--r-- 1 root root 39267 mai 14 19:06 Xorg.1.log
56 -rw-r--r-- 1 root root 53904 mai 14 19:05 Xorg.1.log.oldls -ls /data/LinuxData/tistus/var/log
total 1664
16 -rw-r----- 1 syslog adm 13124 mai 14 19:06 auth.log
12 -rw------- 1 root root 10729 mai 14 19:05 boot.log
12 -rw------- 1 root root 10805 mai 14 14:07 boot.log.1
0 -rw-rw---- 1 root utmp 0 mai 13 18:27 btmp
4 drwxr-x--- 2 root lp 4096 mai 14 14:07 cups
96 -rw-r--r-- 1 root adm 96496 mai 14 19:05 dmesg
96 -rw-r--r-- 1 root adm 96277 mai 13 18:27 dmesg.0
4 drwx--x--x 2 root gdm 4096 mai 13 18:27 gdm3
4 -rw-r--r-- 1 root root 1189 mai 14 19:05 gpu-manager.log
4 -rw-r--r-- 1 root root 1196 mai 14 19:05 gpu-manager-switch.log
284 -rw-r----- 1 syslog adm 287237 mai 14 19:06 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
516 -rw-r----- 1 syslog adm 521165 mai 14 19:06 syslog
428 -rw-r----- 1 syslog adm 435472 mai 14 14:07 syslog.1
4 drwxr-xr-x 2 root root 4096 mai 14 14:07 unattended-upgrades
4 -rw-rw-r-- 1 root utmp 2688 mai 14 19:06 wtmp
40 -rw-r--r-- 1 root root 38867 mai 14 19:06 Xorg.0.log
40 -rw-r--r-- 1 root root 40445 mai 14 19:05 Xorg.0.log.old
40 -rw-r--r-- 1 root root 39267 mai 14 19:06 Xorg.1.log
56 -rw-r--r-- 1 root root 53904 mai 14 19:05 Xorg.1.log.oldTu sais ce que je pense de la présence de ces deux fichiers
128 -rw-r----- 1 syslog adm 128251 mai 13 18:28 kern.log
400 -rw-r----- 1 syslog adm 409012 mai 13 18:51 syslog
Oui, je pense la même chose, je désactiverai ça quand j'aurai réussi à faire un déplacement propre de /var/log
NOTA. Je n'avais pas vu que tu avais fait deux réponses.
désolé 
Par conséquent, il est possible et sûr de stocker le journal dans un autre emplacement. Vous avez juste besoin d'ajouter / changer
Storage=/some-filesystem-with-free-space/some-dir/
dans l' un des fichiers de configuration de journald .
Je ne comprends pas... je dois faire quoi ?
Je vais regarder tes liens.
Hors ligne
#54 Le 14/05/2020, à 19:21
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Bonjour
J'ai avancé un peu dans la recherche. Mais je n'ai pas su solutionner le problème de la limite de la taille des répertoires
Voici un extrait du /etc/fstab
UUID=dcf3a7d4-7c63-41a1-9c86-9c4e2cbbf2fc /DPP ext4 defaults,max_dir_size_kb=1000 0 1
/DPP/MonJournal /var/log/journal none bind 0 0
/DPP/MonVar /var/log none bind 0 0Il est possible que j'ai mal codé le paramètre limitant à 1000KB soit 1 Mo
Tu noteras que les journaux sont ventilés dans deux répertoires différents. Bien que j'aurais préféré que cela soit dans deux partitions afin que le système m'alerte lorsque l'espace disque libre de l'une ou l'autre partition est en train de chuter.
Je pense que l'ordre a de l'importance: En premier le niveau inférieur.
Le test de limite de taille. J'ai tué en cours de copie
a@a:~$ ls -ls /DPP/MonTest/Té*
total 2658772
4 -rwxr-xr-x 1 a a 62 mai 14 18:49 antiX-19-runit_386-base.iso.md5
447748 -rwxr-xr-x 1 a a 458489856 mai 14 18:49 Converti.mp4
240 -rwxr-xr-x 1 a a 243784 mai 14 18:48 'Firefox Setup Stub 50.1.0.exe'
11096 -rwxr-xr-x 1 a a 11359677 mai 14 18:48 genj_install-6755.jar
2199684 -rwxr-xr-x 1 a a 2252472320 mai 14 18:49 PITIVIsuperbowl.aviLe test des journaux
ls -ls /var/log/jou*
total 4
4 drwxr-sr-x+ 2 root systemd-journal 4096 mai 14 18:40 c29f1859251b43e5813595f71100a9f2
ls -ls /DPP/MonVar/jou*
total 4
4 drwxr-sr-x+ 2 root systemd-journal 4096 mai 14 18:40 c29f1859251b43e5813595f71100a9f2
ls -ls /DPP/MonJournal
total 4
4 drwxr-sr-x+ 2 root systemd-journal 4096 mai 14 18:40 c29f1859251b43e5813595f71100a9f2
ls -ls /DPP/MonJournal/c29*
total 16388
8196 -rw-r-----+ 1 root systemd-journal 8388608 mai 14 19:17 system.journal
8192 -rw-r-----+ 1 root systemd-journal 8388608 mai 14 18:58 user-1000.journalEn fait, J'aurais du regarder la signification avant de me lancer
max_dir_size_kb=n
This limits the size of the directories so that any attempt to expand them beyond the specified limit in kilobytes will cause an ENOSPC error. This
is useful in memory-constrained environments, where a very large directory can cause severe performance problems or even provoke the Out Of Memory
killer. (For example, if there is only 512 MB memory available, a 176 MB directory may seriously cramp the system's style.)
Je comprend que c'est la taille de l'espace qui décrit la liste des fichiers du répertoire et pas la taille des fichiers dans le répertoire.
Lorsqu'on lit l'exemple, il n'y a pas de doute à avoir.
Donc tu fabriques une ou deux nouvelles partitions ne contenant que le /var/log et/ou /var/log/journal, Il n'aura même plus besoin de commande bind.
Cela devient du montage classique comme la partition contenant le répertoire /home
Dernière modification par geole (Le 14/05/2020, à 19:51)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#55 Le 14/05/2020, à 19:39
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
J'ai avancé un peu dans la recherche. Mais je n'ai pas su solutionner le problème de la limite de la taille des répertoires
tant pis, ce n'est pas grave. Il faut juste que les logs soient déplacés sur le HDD. S'ils le remplissent je supprimerai et cette fois je créerai une partition dédiée pour l'empêcher de prendre plus. Et puis à priori je vais désactiver syslog et kern.log donc ça n'ira pas au delà de 4go
Je vais tenter d'adapter ton test... je ne suis pas sûr de comprendre ce que je dois faire...
Voilà ce que je tente :
# /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
/data/LinuxData/tistus/var/log /var/log none bind 0 0
#/data/LinuxData/tistus/var/log /var/log none bind max_dir_size_kb=6291456 0 0
#/var/log /data/LinuxData/tistus/var/log max_dir_size_kb=6291456Hors ligne
#56 Le 14/05/2020, à 22:56
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Voila mon dernier test pour faire du standard
1) Création de 2 partitions de la taille qu'on souhaite
a@a:~$ sudo blkid | grep Mon
/dev/sda33: LABEL="MonVAr" UUID="eea46962-768c-4315-95b3-bb8d585aa34b" TYPE="ext4" PARTUUID="84fd2ad6-b95b-4df4-a2c0-b04f38775f03"
/dev/sda34: LABEL="MonJournal" UUID="606da85c-eb8f-4b4c-a6d1-74fe325067d2" TYPE="ext4" PARTUUID="ee427b33-83c4-4dbe-956c-12eab26a118b"2) Mise à jour correcte du fichier /etc/fstab
a@a:~$ cat /etc/fstab | grep var
UUID=606da85c-eb8f-4b4c-a6d1-74fe325067d2 /var/log/journal ext4 defaults 0 1
UUID=eea46962-768c-4315-95b3-bb8d585aa34b /var/log ext4 defaults 0 1
a@a:~$ 3) Reboot et contrôle
a@a:~$ df -h | grep var
/dev/sda33 969M 1,5M 901M 1% /var/log
/dev/sda34 969M 26M 878M 3% /var/log/journal
a@a:~$ Lorsque cela va trop s'emplir je serais informé à condition que cela n'aille pas trop trop vite.
a@a:/var/log/TEST$ df -h | grep var
/dev/sda33 969M 896M 6,5M 100% /var/log
/dev/sda34 969M 26M 878M 3% /var/log/journal
a@a:/var/log/TEST$ et suivi des incidents en direct!!
a@a:/var/log/TEST$ journalctl -f
-- Logs begin at Thu 2020-05-14 22:45:45 CEST. --
mai 14 23:04:16 a anacron[3409]: Normal exit (0 jobs run)
mai 14 23:05:01 a CRON[3413]: pam_unix(cron:session): session opened for user root by (uid=0)
mai 14 23:05:01 a CRON[3414]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
mai 14 23:05:02 a CRON[3413]: pam_unix(cron:session): session closed for user root
mai 14 23:09:20 a systemd-resolved[1114]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
mai 14 23:09:20 a systemd-resolved[1114]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
mai 14 23:09:20 a systemd-resolved[1114]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
mai 14 23:09:20 a systemd-resolved[1114]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
mai 14 23:09:23 a rtkit-daemon[1671]: Supervising 4 threads of 2 processes of 1 users.
mai 14 23:09:23 a rtkit-daemon[1671]: Supervising 4 threads of 2 processes of 1 users.
mai 14 23:15:01 a CRON[3490]: pam_unix(cron:session): session opened for user root by (uid=0)
mai 14 23:15:01 a CRON[3491]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
mai 14 23:15:01 a CRON[3490]: pam_unix(cron:session): session closed for user rootAJOUT.
Suite des essais
Avec le script suivant dont le paramétrage peut être adapté,, j'ai pu tester le remplissage et l'auto-épuration du journal système
sudo -i echo "écrivons dans le journal"
y=0
for (( nbr=0; nbr < 542100; nbr++ )); do
x=`echo $(($nbr/500))`
echo "Essai $nbr $(date) =====================================================================================================" >/dev/kmsg
if [ $x -gt $y ]; then
echo -ne "\r " $nbr ; y=$x
sleep 1
fi
doneEn ouvrant un autre terminal, je peux suivre l'évolution et constater que lorsque le volume collecté, dépasse 10% de la taille de la partition plus la taille du journal en cours, il y a une diminution drastique de l'espace utilisé. C'est bien un fonctionnement en dents de scie.
df -h | grep var
/dev/sda33 969M 953M 0 100% /var/log
/dev/sda34 969M 122M 782M 14% /var/log/journalOn constate que les journaux anciens sont bien supprimés.
journalctl --list-boots
0 77fb70e73abc451695a730be8ad0dc51 Fri 2020-05-15 13:23:09 CEST—Fri 2020-05-15 13:31:16 CESTDonc, tout fonctionne parfaitement bien pour la collecte moderne.
NOTA: j'avais ajouté cette ligne
SystemMaxFileSize=10MDans le fichier /etc/systemd/joutnald.conf. C'est probablement inutile.
Pour l'ancienne collecte, que j'ai réactivée, elle fonctionne comme décrit. Cela s'emplit tranquillement. J'ai forcé un peu en y ajoutant un répertoire TEST dans lequel j'ai mis des fichiers volumineux!
le message d'erreur disant qu'il n'y a plus de place dans la partition contenant /var/log est apparu à l'écran dans une petite fenêtre.
De temps en temps, je faisais cette commande qui a fini par ne plus pouvoir s'exécuter
sudo logrotate -f /etc/logrotate.conf Et on y voit une trace dans la collecte
mai 15 13:34:35 a rsyslogd[1189]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
journalctl | grep "No space left on device" | wc -w
121752a@a:/var/log$ ls -ls
total 85512
0 -rw-r----- 1 root adm 0 mai 15 10:08 apport.log
4 -rw-r----- 1 root adm 624 mai 14 23:32 apport.log.1
0 -rw-rw---- 1 root utmp 0 mai 15 12:05 btmp
0 -rw-rw---- 1 root utmp 0 mai 15 11:49 btmp.1
4 drwxr-x--- 2 root lp 4096 mai 15 12:05 cups
4 drwx--x--x 2 root gdm 4096 mai 14 22:46 gdm3
4 -rw-r--r-- 1 root root 1548 mai 15 10:03 gpu-manager.log
4 drwxr-sr-x+ 4 root systemd-journal 4096 mai 14 22:42 journal
0 -rw-r----- 1 syslog adm 0 mai 15 13:06 kern.log
8 -rw-r----- 1 syslog adm 4955 mai 15 11:25 kern.log.1
216 -rw-r----- 1 syslog adm 217239 mai 15 10:05 kern.log.2
0 -rw-rw-r-- 1 root utmp 0 mai 14 22:36 lastlog
16 drwx------ 2 root root 16384 mai 14 22:28 lost+found
6740 -rw-r----- 1 syslog adm 6901760 mai 15 13:34 syslog
35860 -rw-r----- 1 syslog adm 36715367 mai 15 11:49 syslog.1
48 -rw-r----- 1 syslog adm 45600 mai 15 10:05 syslog.2.gz
4 drwxr-xr-x 2 root root 4096 mai 15 13:45 TEST
4 drwxr-xr-x 2 root root 4096 mai 14 22:46 unattended-upgrades
0 -rw-r----- 1 syslog adm 0 mai 15 13:34 user.log
6740 -rw-r----- 1 syslog adm 6901760 mai 15 12:05 user.log.1
35856 -rw-r----- 1 syslog adm 36710678 mai 15 11:49 user.log.2
0 -rw-rw-r-- 1 root utmp 0 mai 15 12:05 wtmp
0 -rw-rw-r-- 1 root utmp 0 mai 15 11:49 wtmp.1MEME TYPE de manipulation en créant un répertoire TEST dans /var/log/journal et en le remplissant.
On est informé que la partition n'a plus de place disque et cela cesse d'écrire.
CEPENDANT, le reboot se passe sans difficulté. On est informé qu'il n'y a toujours pas de place disque, Mais, il y a certainement du y avoir une épuration du journal le plus ancien car, il y a maintenant deux journaux et la fin du premier journal montre la fin de collecte sans la trace de la terminaison.
journalctl --list-boots
Journal file /var/log/journal/c29f1859251b43e5813595f71100a9f2/user-1000.journal is truncated, ignoring file.
-1 77fb70e73abc451695a730be8ad0dc51 Fri 2020-05-15 13:27:44 CEST—Fri 2020-05-15 13:58:13 CEST
0 d9a645da4a6543ee83648fc09eb2f85b Fri 2020-05-15 14:04:02 CEST—Fri 2020-05-15 14:07:21 CEST journalctl -b-1 |tail
Journal file /var/log/journal/c29f1859251b43e5813595f71100a9f2/user-1000.journal is truncated, ignoring file.
mai 15 13:58:13 a unknown: Essai 9214 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9215 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9216 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9217 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9218 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9219 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9220 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9221 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9222 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================
mai 15 13:58:13 a unknown: Essai 9223 vendredi 15 mai 2020, 13:58:13 (UTC+0200) =====================================================================================================df -h |grep journal
/dev/sda34 969M 953M 0 100% /var/log/journalDernière modification par geole (Le 15/05/2020, à 14:20)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#57 Le 15/05/2020, à 14:39
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
d'accord
et du coup ça permet de créer les fichiers manquants ?
4 drwxr-sr-x+ 3 root systemd-journal 4096 janv. 26 12:00 journal
4 drwxr-xr-x 2 root root 4096 janv. 8 13:02 journalje ne comprends pas quel changement permet à ces fichiers d'être créés entre cette méthode. Je pense que je vais l'appliquer de la même manière que toi, je vais regarder comment ça marche. (si tu as trouvé d'autres liens d'intérêt sur le fonctionnement je les veux bien, en attendant je vais chercher.
Je vais désactiver la journalisation syslog et kern.log au passage, pas la peine d'attendre plus pour le faire.
Hors ligne
#58 Le 15/05/2020, à 16:33
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Bonjour
Lorsque le nouveau répertoire qui est pointé par /var/log ne contient rien, le logiciel fait des créations de fichiers si on ne les a pas préalablement importés. (Pour mon test, j'en ai profité)
N'oublie pas que, de façon standard, lorsque la création des fichiers kern.log et syslog est invalidée, les autres fichiers de log sont très peu actifs et que le répertoire contenant le journal est limité automatiquement à une taille de 10% de la partition le contenant avec un maxima de 4 Go.
Dernière modification par geole (Le 15/05/2020, à 16:35)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#59 Le 15/05/2020, à 18:31
- moko138
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Attention à vos fstab !
1) Il ne faut pas remplir les deux derniers champs (<dump> <pass>) pour un répertoire !
Car ces nombres (0, 1 ou 2) concernent les systèmes de fichiers (FS), et donc n'auraient pas de sens - dans le meilleur des cas - pour les répertoires que vous mettez dessus !
# <file system> <mount point> <type> <options> <dump> <pass>
# Montage du FS :
UUID=(...) /data/LinuxData ext4 <options> 0 2
# Placer un répertoire sur le FS précédent :
/var/log /data/LinuxData/var/log max_dir_size_kb=300999= =
2) Ceci :
/var/log/ /data/LinuxData/tistus/var/log max_dir_size_kb=300999
NE m'inspire PAS confiance.
Car /var/log est un répertoire système
- qui appartient à root
- et qui doit être actif bien avant que l'utilisateur tistus soit logué.
= =
3)
Je comprend que c'est la taille de l'espace qui décrit la liste des fichiers du répertoire et pas la taille des fichiers dans le répertoire.
man mount dit :
Options de montage pour ext4
max_dir_size_kb=n
Cela limite la taille des répertoires
C'est le poids du répertoire.
Et ce poids peut être mesuré avec du -sh.
Mais il ne faut pas demander à ls -l de mesurer correctement le poids d'un répertoire !
Et de toute façon, l'option max_dir_size_kb= est bien moins intéressante que la solution dont j'ai donné le lien en #44 §2.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#60 Le 15/05/2020, à 21:17
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
2) Ceci :
/var/log/ /data/LinuxData/tistus/var/log max_dir_size_kb=300999
NE m'inspire PAS confiance.
Car /var/log est un répertoire système
- qui appartient à root
- et qui doit être actif bien avant que l'utilisateur tistus soit logué.
Pardon de t'avoir fait peur, mais je pense que ça ne va pas poser problème. Le tistus est un dossier comme un autre enfin presque, c'est moi qui l'ai créé afin de contenir les dossiers (Bureau, Documents, Téléchargements...) pour qu'ils ne soient pas sur le SSD.
Pour résumer mon installation :
Un SSD contenant le dual boot Linux-Windows
Un HDD contenant une partition EXT4 et une partition NTFS
La partition EXT4 contient tous mes fichiers. Grace à l'application Disques j'ai demandé à ce que cette partition soit montée au Démarrage du système sous /data/LinuxData. Dans ce stockage j'ai créé un dossier tistus et j'ai remplacé mes dossiers dans le dossier personnel par des liens vers des dossiers du même nom dans ce dossier tistus. Comme ça chaque téléchargement par exemple part sur le HDD dans /data/LinuxData/tistus/Téléchargements grâce au lien /home/tistus/Téléchargements.
La logique de placer /var/log dans ce dossier c'est que je ne touche JAMAIS au dossier /data/LinuxData/tistus par principe : je me sert des liens qui me permettent de m'en servir de manière transparente.
Placer /var/log dans /data/LinuxData sera pareil que de la placer dans /data/LinuxData/tistus, aucune conséquence à priori.
fin résumé
Voici mon 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
#/data/LinuxData/tistus/var/log /var/log none bind 0 0
#/data/LinuxData/tistus/var/log /var/log none bind max_dir_size_kb=6291456 0 0
#/var/log /data/LinuxData/tistus/var/log max_dir_size_kb=6291456
#/dev/disk/by-uuid/2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData auto nosuid,nodev,nofail 0 0
UUID=2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData ext4 nosuid,nodev,nofail 0 0
/data/LinuxData/tistus/var/log /var/log none bind 0 0La ligne suivante est définie par disques, je préférerai ne pas la changer si possible car elle marche très bien depuis plusieurs versions / installations d’Ubuntu et elle est créée par le logiciel. Si je la modifie je la modifie avec ledit logiciel. Mais vous savez ce que vous faites, si je dois la modifier, dites moi juste exactement comment.
UUID=2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData ext4 nosuid,nodev,nofail 0 0Ces lignes sont des tests qui n'ont pas fonctionné pour monter /var/log dans /data/LinuxData :
#/data/LinuxData/tistus/var/log /var/log none bind 0 0
#/data/LinuxData/tistus/var/log /var/log none bind max_dir_size_kb=6291456 0 0
#/var/log /data/LinuxData/tistus/var/log max_dir_size_kb=6291456
#/dev/disk/by-uuid/2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData auto nosuid,nodev,nofail 0 0Cette ligne inspirée de celle geole semble fonctionner car je trouve le même contenu dans /var/log et /data/LinuxData/tistus/var/log :
/data/LinuxData/tistus/var/log /var/log none bind 0 0Tu me dis que ce n'est pas bon, donc je vais remplacer par ta ligne et redémarrer pour voir si ça marche. Je ne vais néanmoins pas tout de suite mettre l’option max_dir_size_kb=300999.
Je préfère commencer par quelques chose qui marche avant d'empêcher les débordements. Mon /data/LinuxData fait environs 1,9 To, si /var/log est déplacé dessus et fonctionne de manière correcte la limitation de sa taille est pour moi secondaire, mon système acceptera de démarrer même si les 1,9To sont remplis vu que mon système n'est pas dessus.
En la situation actuelle le principal problème semble être que ceci manque :
4 drwxr-sr-x+ 3 root systemd-journal 4096 janv. 26 12:00 journal
4 drwxr-xr-x 2 root root 4096 janv. 8 13:02 journalSi en remplaçant par ta ligne @moko138 ça permet de changer ça... C'est vraiment parfait, genre petits oignons. Si tu as une idée de comment monter /var/log de manière à ce qu'il n'y ai rien qui manque, c'est le principal.
Pour commencer je remplace :
/data/LinuxData/tistus/var/log /var/log none bind 0 0par :
/var/log /data/LinuxData/tistus/var/logpour tester sans les options qui ne s'appliquent pas à un répertoire comme tu le dissais.
Pour être sûr, avec quel carractère doit on espacer /var/log et /data/LinuxData/tistus/var/log, un espace ? une tabultation ?
voici le résultat de : du -sh
20G .Merci pour le rapel de ton message sur comment limiter la taille, je vais essayer de m'en souvenir cette fois, mais d'abord je vais cooriger le montage lui même.
Dernière modification par MJ_Tistus (Le 15/05/2020, à 21:20)
Hors ligne
#61 Le 15/05/2020, à 21:31
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
/var/log /data/LinuxData/tistus/var/logça ne marche pas, maintenant les logs sont à nouveau sur le SDD
ls -ls /var/log
total 7596
44 -rw-r--r-- 1 root root 39340 mai 13 11:23 alternatives.log
0 -rw-r----- 1 root adm 0 mai 5 17:08 apport.log
4 -rw-r----- 1 root adm 1730 mai 4 17:20 apport.log.1
4 drwxr-xr-x 2 root root 4096 mai 13 11:23 apt
40 -rw-r----- 1 syslog adm 33979 mai 15 21:26 auth.log
52 -rw-r----- 1 syslog adm 45655 mai 7 17:00 auth.log.1
44 -rw------- 1 root root 43552 mai 15 21:25 boot.log
16 -rw------- 1 root root 12321 mai 13 00:00 boot.log.1
12 -rw------- 1 root root 9228 mai 12 16:29 boot.log.2
4 -rw------- 1 root root 1551 mai 7 16:59 boot.log.3
12 -rw------- 1 root root 9140 mai 6 18:14 boot.log.4
936 -rw------- 1 root root 955536 mai 5 17:08 boot.log.5
104 -rw-r--r-- 1 root root 104003 avril 23 09:33 bootstrap.log
0 -rw-rw---- 1 root utmp 0 avril 23 09:32 btmp
4 drwxr-xr-x 2 root root 4096 mai 13 00:00 cups
4 drwxr-xr-x 2 root root 4096 avril 8 17:59 dist-upgrade
96 -rw-r--r-- 1 root adm 95792 mai 15 21:25 dmesg
96 -rw-r--r-- 1 root adm 96257 mai 13 18:12 dmesg.0
24 -rw-r--r-- 1 root adm 20581 mai 13 10:43 dmesg.1.gz
24 -rw-r--r-- 1 root adm 20713 mai 13 01:08 dmesg.2.gz
24 -rw-r--r-- 1 root adm 20615 mai 12 21:44 dmesg.3.gz
24 -rw-r--r-- 1 root adm 20634 mai 12 16:29 dmesg.4.gz
1228 -rw-r--r-- 1 root root 1253003 mai 13 11:23 dpkg.log
8 -rw-r--r-- 1 root root 32032 mai 4 22:25 faillog
12 -rw-r--r-- 1 root root 11125 mai 3 13:59 fontconfig.log
4 drwx--x--x 2 root gdm 4096 oct. 7 2019 gdm3
4 -rw-r--r-- 1 root root 1189 mai 15 21:25 gpu-manager.log
4 -rw-r--r-- 1 root root 1196 mai 13 18:26 gpu-manager-switch.log
4 drwxr-xr-x 3 root root 4096 avril 23 09:36 hp
4 drwxrwxr-x 2 root root 4096 mai 3 12:30 installer
4 drwxr-sr-x+ 3 root systemd-journal 4096 mai 3 12:49 journal
552 -rw-r----- 1 syslog adm 562570 mai 13 18:26 kern.log
1244 -rw-r----- 1 syslog adm 1270559 mai 12 16:29 kern.log.1
44 -rw-rw-r-- 1 root utmp 292292 mai 4 22:25 lastlog
4 drwxr-xr-x 2 root root 4096 sept. 5 2019 openvpn
4 drwx------ 2 root root 4096 avril 23 09:32 private
4 drwx------ 2 speech-dispatcher root 4096 janv. 19 19:26 speech-dispatcher
1344 -rw-r----- 1 syslog adm 1369855 mai 13 18:26 syslog
848 -rw-r----- 1 syslog adm 867302 mai 13 00:00 syslog.1
36 -rw-r----- 1 syslog adm 32788 mai 12 16:29 syslog.2.gz
32 -rw-r----- 1 syslog adm 31679 mai 7 16:59 syslog.3.gz
36 -rw-r----- 1 syslog adm 33293 mai 6 18:14 syslog.4.gz
416 -rw-r----- 1 syslog adm 422694 mai 5 17:08 syslog.5.gz
0 -rw------- 1 root root 0 avril 23 09:33 ubuntu-advantage.log
4 drwxr-x--- 2 root adm 4096 mai 4 17:20 unattended-upgrades
24 -rw-rw-r-- 1 root utmp 17280 mai 15 21:25 wtmp
40 -rw-r--r-- 1 root root 38867 mai 15 21:25 Xorg.0.log
40 -rw-r--r-- 1 root root 40445 mai 13 18:26 Xorg.0.log.old
40 -rw-r--r-- 1 root root 39267 mai 15 21:25 Xorg.1.log
44 -rw-r--r-- 1 root root 41998 mai 13 18:26 Xorg.1.log.oldls -ls /data/LinuxData/tistus/var/log
total 4140
4 -rw-r----- 1 root adm 2517 mai 15 10:07 apport.log
4 drwxr-xr-x 2 root root 4096 mai 15 10:06 apt
40 -rw-r----- 1 syslog adm 35397 mai 15 21:24 auth.log
24 -rw------- 1 root root 22289 mai 15 19:15 boot.log
24 -rw------- 1 root root 21750 mai 15 09:14 boot.log.1
12 -rw------- 1 root root 10805 mai 14 14:07 boot.log.2
0 -rw-rw---- 1 root utmp 0 mai 13 18:27 btmp
4 drwxr-x--- 2 root lp 4096 mai 15 09:14 cups
96 -rw-r--r-- 1 root adm 96488 mai 15 19:15 dmesg
96 -rw-r--r-- 1 root adm 96624 mai 15 15:20 dmesg.0
24 -rw-r--r-- 1 root adm 20626 mai 14 19:42 dmesg.1.gz
24 -rw-r--r-- 1 root adm 20726 mai 14 19:05 dmesg.2.gz
24 -rw-r--r-- 1 root adm 20604 mai 13 18:27 dmesg.3.gz
8 -rw-r--r-- 1 root root 8084 mai 15 10:06 dpkg.log
4 drwx--x--x 2 root gdm 4096 mai 13 18:27 gdm3
4 -rw-r--r-- 1 root root 1189 mai 15 19:15 gpu-manager.log
4 -rw-r--r-- 1 root root 1196 mai 15 21:24 gpu-manager-switch.log
484 -rw-r----- 1 syslog adm 494153 mai 15 15:19 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
2148 -rw-r----- 1 syslog adm 2194844 mai 15 15:19 syslog
864 -rw-r----- 1 syslog adm 879278 mai 15 09:14 syslog.1
60 -rw-r----- 1 syslog adm 60260 mai 14 14:07 syslog.2.gz
4 drwxr-xr-x 2 root root 4096 mai 14 14:07 unattended-upgrades
8 -rw-rw-r-- 1 root utmp 7680 mai 15 21:24 wtmp
40 -rw-r--r-- 1 root root 40445 mai 15 21:24 Xorg.0.log
40 -rw-r--r-- 1 root root 40445 mai 15 15:22 Xorg.0.log.old
48 -rw-r--r-- 1 root root 47951 mai 15 21:24 Xorg.1.log
44 -rw-r--r-- 1 root root 41998 mai 15 15:22 Xorg.1.log.oldjournal est revenu... parce que c'est revenu au point de départ.
Je teste
/var/log /data/LinuxData/var/log max_dir_size_kb=300999copié collé cette fois, pour être sûr...
EDIT ne marche pas non plus :
ls -ls /var/log
total 7616
44 -rw-r--r-- 1 root root 39340 mai 13 11:23 alternatives.log
0 -rw-r----- 1 root adm 0 mai 5 17:08 apport.log
4 -rw-r----- 1 root adm 1730 mai 4 17:20 apport.log.1
4 drwxr-xr-x 2 root root 4096 mai 13 11:23 apt
44 -rw-r----- 1 syslog adm 38794 mai 15 21:33 auth.log
52 -rw-r----- 1 syslog adm 45655 mai 7 17:00 auth.log.1
60 -rw------- 1 root root 53798 mai 15 21:32 boot.log
16 -rw------- 1 root root 12321 mai 13 00:00 boot.log.1
12 -rw------- 1 root root 9228 mai 12 16:29 boot.log.2
4 -rw------- 1 root root 1551 mai 7 16:59 boot.log.3
12 -rw------- 1 root root 9140 mai 6 18:14 boot.log.4
936 -rw------- 1 root root 955536 mai 5 17:08 boot.log.5
104 -rw-r--r-- 1 root root 104003 avril 23 09:33 bootstrap.log
0 -rw-rw---- 1 root utmp 0 avril 23 09:32 btmp
4 drwxr-xr-x 2 root root 4096 mai 13 00:00 cups
4 drwxr-xr-x 2 root root 4096 avril 8 17:59 dist-upgrade
96 -rw-r--r-- 1 root adm 96457 mai 15 21:32 dmesg
96 -rw-r--r-- 1 root adm 95792 mai 15 21:25 dmesg.0
24 -rw-r--r-- 1 root adm 20658 mai 13 18:12 dmesg.1.gz
24 -rw-r--r-- 1 root adm 20581 mai 13 10:43 dmesg.2.gz
24 -rw-r--r-- 1 root adm 20713 mai 13 01:08 dmesg.3.gz
24 -rw-r--r-- 1 root adm 20615 mai 12 21:44 dmesg.4.gz
1228 -rw-r--r-- 1 root root 1253003 mai 13 11:23 dpkg.log
8 -rw-r--r-- 1 root root 32032 mai 4 22:25 faillog
12 -rw-r--r-- 1 root root 11125 mai 3 13:59 fontconfig.log
4 drwx--x--x 2 root gdm 4096 oct. 7 2019 gdm3
4 -rw-r--r-- 1 root root 1189 mai 15 21:32 gpu-manager.log
4 -rw-r--r-- 1 root root 1196 mai 15 21:31 gpu-manager-switch.log
4 drwxr-xr-x 3 root root 4096 avril 23 09:36 hp
4 drwxrwxr-x 2 root root 4096 mai 3 12:30 installer
4 drwxr-sr-x+ 3 root systemd-journal 4096 mai 3 12:49 journal
552 -rw-r----- 1 syslog adm 562570 mai 13 18:26 kern.log
1244 -rw-r----- 1 syslog adm 1270559 mai 12 16:29 kern.log.1
44 -rw-rw-r-- 1 root utmp 292292 mai 4 22:25 lastlog
4 drwxr-xr-x 2 root root 4096 sept. 5 2019 openvpn
4 drwx------ 2 root root 4096 avril 23 09:32 private
4 drwx------ 2 speech-dispatcher root 4096 janv. 19 19:26 speech-dispatcher
1344 -rw-r----- 1 syslog adm 1369855 mai 13 18:26 syslog
848 -rw-r----- 1 syslog adm 867302 mai 13 00:00 syslog.1
36 -rw-r----- 1 syslog adm 32788 mai 12 16:29 syslog.2.gz
32 -rw-r----- 1 syslog adm 31679 mai 7 16:59 syslog.3.gz
36 -rw-r----- 1 syslog adm 33293 mai 6 18:14 syslog.4.gz
416 -rw-r----- 1 syslog adm 422694 mai 5 17:08 syslog.5.gz
0 -rw------- 1 root root 0 avril 23 09:33 ubuntu-advantage.log
4 drwxr-x--- 2 root adm 4096 mai 4 17:20 unattended-upgrades
24 -rw-rw-r-- 1 root utmp 18816 mai 15 21:32 wtmp
40 -rw-r--r-- 1 root root 38867 mai 15 21:32 Xorg.0.log
40 -rw-r--r-- 1 root root 40445 mai 15 21:31 Xorg.0.log.old
40 -rw-r--r-- 1 root root 39267 mai 15 21:32 Xorg.1.log
44 -rw-r--r-- 1 root root 41998 mai 15 21:31 Xorg.1.log.oldls -ls /data/LinuxData/var/log
total 0Le dossier est créé, mais il ne contient rien.
Je suppose que c'est l'inverse qu'il faut pour que /var/log soit monté sur le HDD :
/data/LinuxData/var/log /var/logTest
ls -ls /data/LinuxData/var/log
total 0ls -ls /var/log
total 7628
44 -rw-r--r-- 1 root root 39340 mai 13 11:23 alternatives.log
0 -rw-r----- 1 root adm 0 mai 5 17:08 apport.log
4 -rw-r----- 1 root adm 1730 mai 4 17:20 apport.log.1
4 drwxr-xr-x 2 root root 4096 mai 13 11:23 apt
48 -rw-r----- 1 syslog adm 43143 mai 15 21:39 auth.log
52 -rw-r----- 1 syslog adm 45655 mai 7 17:00 auth.log.1
68 -rw------- 1 root root 64754 mai 15 21:38 boot.log
16 -rw------- 1 root root 12321 mai 13 00:00 boot.log.1
12 -rw------- 1 root root 9228 mai 12 16:29 boot.log.2
4 -rw------- 1 root root 1551 mai 7 16:59 boot.log.3
12 -rw------- 1 root root 9140 mai 6 18:14 boot.log.4
936 -rw------- 1 root root 955536 mai 5 17:08 boot.log.5
104 -rw-r--r-- 1 root root 104003 avril 23 09:33 bootstrap.log
0 -rw-rw---- 1 root utmp 0 avril 23 09:32 btmp
4 drwxr-xr-x 2 root root 4096 mai 13 00:00 cups
4 drwxr-xr-x 2 root root 4096 avril 8 17:59 dist-upgrade
96 -rw-r--r-- 1 root adm 96115 mai 15 21:38 dmesg
96 -rw-r--r-- 1 root adm 96457 mai 15 21:32 dmesg.0
24 -rw-r--r-- 1 root adm 20620 mai 15 21:25 dmesg.1.gz
24 -rw-r--r-- 1 root adm 20658 mai 13 18:12 dmesg.2.gz
24 -rw-r--r-- 1 root adm 20581 mai 13 10:43 dmesg.3.gz
24 -rw-r--r-- 1 root adm 20713 mai 13 01:08 dmesg.4.gz
1228 -rw-r--r-- 1 root root 1253003 mai 13 11:23 dpkg.log
8 -rw-r--r-- 1 root root 32032 mai 4 22:25 faillog
12 -rw-r--r-- 1 root root 11125 mai 3 13:59 fontconfig.log
4 drwx--x--x 2 root gdm 4096 oct. 7 2019 gdm3
4 -rw-r--r-- 1 root root 1189 mai 15 21:38 gpu-manager.log
4 -rw-r--r-- 1 root root 1196 mai 15 21:38 gpu-manager-switch.log
4 drwxr-xr-x 3 root root 4096 avril 23 09:36 hp
4 drwxrwxr-x 2 root root 4096 mai 3 12:30 installer
4 drwxr-sr-x+ 3 root systemd-journal 4096 mai 3 12:49 journal
552 -rw-r----- 1 syslog adm 562570 mai 13 18:26 kern.log
1244 -rw-r----- 1 syslog adm 1270559 mai 12 16:29 kern.log.1
44 -rw-rw-r-- 1 root utmp 292292 mai 4 22:25 lastlog
4 drwxr-xr-x 2 root root 4096 sept. 5 2019 openvpn
4 drwx------ 2 root root 4096 avril 23 09:32 private
4 drwx------ 2 speech-dispatcher root 4096 janv. 19 19:26 speech-dispatcher
1344 -rw-r----- 1 syslog adm 1369855 mai 13 18:26 syslog
848 -rw-r----- 1 syslog adm 867302 mai 13 00:00 syslog.1
36 -rw-r----- 1 syslog adm 32788 mai 12 16:29 syslog.2.gz
32 -rw-r----- 1 syslog adm 31679 mai 7 16:59 syslog.3.gz
36 -rw-r----- 1 syslog adm 33293 mai 6 18:14 syslog.4.gz
416 -rw-r----- 1 syslog adm 422694 mai 5 17:08 syslog.5.gz
0 -rw------- 1 root root 0 avril 23 09:33 ubuntu-advantage.log
4 drwxr-x--- 2 root adm 4096 mai 4 17:20 unattended-upgrades
24 -rw-rw-r-- 1 root utmp 19584 mai 15 21:38 wtmp
40 -rw-r--r-- 1 root root 38867 mai 15 21:38 Xorg.0.log
40 -rw-r--r-- 1 root root 40445 mai 15 21:38 Xorg.0.log.old
40 -rw-r--r-- 1 root root 39267 mai 15 21:39 Xorg.1.log
44 -rw-r--r-- 1 root root 41998 mai 15 21:38 Xorg.1.log.oldJ'avoue que cette fois je pensais que ça marcherai comme juste avant avec la ligne adaptée de celle de geole... Les options qu'il y a dans sa ligne semblent changer quelque chose, là le dossier sur le HDD est vide, les logs sont sur le SSD dans les deux cas...
Dernière modification par MJ_Tistus (Le 15/05/2020, à 21:44)
Hors ligne
#62 Le 16/05/2020, à 00:11
- moko138
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Merci beaucoup de tes retours ! 
Dans fstab, espace ou tabulation ou les deux, produisent le même effet.
Pour sudo du -sh, tu as oublié de dire dans quel répertoire tu l'as lancé...
Ce qui serait pertinent, c'est de comparer
sudo du -xah -d2 /var/log | sort -h | tail -20et
sudo du -xah -d2 /data/LinuxData/var/log | sort -h | tail -20et de suivre leur évolution, pour voir quel test cesse de faire enfler le premier des 2 retours.
= =
Tu dis :
Ces lignes sont des tests qui n'ont pas fonctionné pour monter /var/log dans /data/LinuxData :
#/data/LinuxData/tistus/var/log /var/log none bind 0 0 (...)Cette ligne inspirée de celle geole semble fonctionner car je trouve le même contenu dans /var/log et /data/LinuxData/tistus/var/log :
/data/LinuxData/tistus/var/log /var/log none bind 0 0
Or c'est la même, à part le "#" que, j'espère, tu n'as rajouté qu'après le test.
Donc l'échec du test n'était pas imputable à la ligne elle-même, mais à un autre facteur, à identifier.
= =
Concernant l'erreur "spurious", tu devrais lire
./viewtopic.php?pid=21864201#p21864201 "Boot d'Ubuntu anormalement long", #34
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#63 Le 16/05/2020, à 00:22
- moko138
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Quel que soit le contenu de ton fstab, termine-le par une ligne
#ou
# Dernière modif en date du...Car il faut une fin de ligne pour qu'une ligne y soit prise en compte !
C'était peut-être le facteur à identifier.
= =
Et quand tu modifies ton fstab, afin que la modif soit prise en compte,
soit tu redémarres, soit (plus rapide) tu exécutes
sudo mount -a%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#64 Le 16/05/2020, à 17:18
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Quel que soit le contenu de ton fstab, termine-le par une ligne
#ou
# Dernière modif en date du...Car il faut une fin de ligne pour qu'une ligne y soit prise en compte !
C'était peut-être le facteur à identifier.
= =
Et quand tu modifies ton fstab, afin que la modif soit prise en compte,
soit tu redémarres, soit (plus rapide) tu exécutessudo mount -a
Je peux tenter de mettre le #, j'avais déjà vu cette histoire de laisser une ligne à la fin mais à chaque redémarrage elle disparaît et ça semble marcher sans donc...
sudo mount -a c'est sans danger ? j'ai redémarré à chaque test mais je vais tenter
Hors ligne
#65 Le 16/05/2020, à 17:32
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Pour sudo du -sh, tu as oublié de dire dans quel répertoire tu l'as lancé...
Ce qui serait pertinent, c'est de comparersudo du -xah -d2 /var/log | sort -h | tail -20
et
sudo du -xah -d2 /data/LinuxData/var/log | sort -h | tail -20
et de suivre leur évolution, pour voir quel test cesse de faire enfler le premier des 2 retours.
Je n'ai pas compris la fonction de du -sh, je l'ai juste lancé dans un nouveau terminal.
et je ne comprends pas le "et de suivre leur évolution, pour voir quel test cesse de faire enfler le premier des 2 retours"...
Or c'est la même, à part le "#" que, j'espère, tu n'as rajouté qu'après le test.
je le commentais parce qu'il était au mauvais endroit, c'est tout, aucun problème pour cette ligne
/data/LinuxData/tistus/var/log /var/log none bind 0 0à mon avis le 0 0 est pour les partitions donc tu as raison, mais vu que ça marche je pense que les options "none bind" sont nécessaire pour monter /var/log dans /data/LinuxData/var/log
# <file system> <mount point> <type> <options> <dump> <pass>dans quel ordre doit on mettre /data/LinuxData/tistus/var/log et /var/log si on veut que /var/log soit monté dans /data/LinuxData/tistus/var/log et pas l'inverse ?
Comment faire pour le dossier journal soir présent ?
Hors ligne
#66 Le 16/05/2020, à 17:52
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
ah ! ça se précise
La ligne ne marche pas :
sudo mount -a
[sudo] Mot de passe de tistus :
mount: /etc/fstab : erreur d'analyse à la ligne 20 — ignorée# /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
#/data/LinuxData/tistus/var/log /var/log none bind 0 0
#/data/LinuxData/tistus/var/log /var/log none bind max_dir_size_kb=6291456 0 0
#/var/log /data/LinuxData/tistus/var/log max_dir_size_kb=6291456
#/dev/disk/by-uuid/2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData auto nosuid,nodev,nofail 0 0
UUID=2bbc48ef-8962-4ab6-b6b6-24e5a0b92b7d /data/LinuxData ext4 nosuid,nodev,nofail 0 0
#/data/LinuxData/tistus/var/log /var/log none bind 0 0
/data/LinuxData/var/log /var/log
#ça marche si je met none bind derrière, donc il y a des options nécessaire même avec les répertoires.
Par contre les deux répertoires ont été vidés, donc ça doit être l'inverse, je pense que c'est /data/LinuxData/var/log qui a été monté sur /var/log
La correction ne rempli pas le dossier à nouveau, je vais redémarrer pour voir
EDIT
/var/log /data/LinuxData/var/log none bindsemble marcher mais en fait ce n'est pas le cas, si on met un fichier dans /data/LinuxData/var/log avec les droits utilisateurs on peut voir que l'espace est pris sur le SSD donc ça ne sert à rien...
EDIT
alors en fait c'est bien l'inverse qu'il faut faire :
/data/LinuxData/var/log /var/log none bindcette fois c'est écris sur le HDD mais on a à nouveau le problème que j'avais avec la commande de geole, c'est à dire qu'il manque des fichiers et dossiers comme journal. c'est chiant...
Dernière modification par MJ_Tistus (Le 16/05/2020, à 18:40)
Hors ligne
#67 Le 16/05/2020, à 18:38
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Bonjour
Pour le dernier point, je n'ai pas fait fait le test de permuter l'ordre des bind
Lorsque tu as installé normalement la première fois, le répertoire /var/log a été créé. Il y a lieu de penser que le sous-répertoire journal a été créé dans la foulée. Cette action suffit pour collecter
J'ai fait un test montrant que le log du journal peut être installé dans une partition et les autres logs dans une autre partition
J'ai bindé en premier une partition sur /var/log/journal
J'ai bindé en second une partition sur /var/log
J'ai constaté que tout fonctionnait comme prévu, Je peux toujours tenter de faire l'inverse pour voir ce que cela donne.
Mais, dans la réalité, avoir deux partitions pour les LOG me semble une absurdité. Une seule suffit bien puisque les log archivés de systemd s'adaptent en permanence à l'espace disponible dans la partition.
La règle est assez complexe (man journald.conf ) Depuis hier, j'ai une traduction google pas totalement mise en forme.
Ce que j'en comprends (Mais il me semble que moko138 a mis un lien)
a) Le volume total des log archive ne peut dépasser 10% de l'espace disque de la partition et ne dépassera jamais 4 Gio
En clair, si tu fais une partition dédiée au journal d'une taille de 40 Go, il y aura 36 Go de perdus.
Si tu fais une partition dédiée au journal de 4 Go, l'historique du journal ne fera que 400Mo
A cela, il faut ajouter la taille du fichier courant, En standard, il fait 100 Mo , On peut en faire un de 1 Go ou de 10 Mo.
b) Le journal systemd fait en sorte de supprimer des journaux lorsqu'il constate que la partition qui le contient à un espace disque libre inférieur à 15% de la taille de la partition.
Si le journal partage une partition avec d'autres applications et qu'il a atteint 4 Go et que d'autres applications ont besoin de place disque, il va supprimer tous ses fichiers historiques sauf le courant afin que les autres en profitent
c) La documentation attire notre attention sur le fait que le fichier courant est prévu pour 1 mois de collecte. Je n'ai pas tout compris mais l'idée serait que un mois ce nest pas nécessairement bon ( it might make sense to change this value from the default of one month.) 7 jours?
Il est donc clair qu'une seule partition dédiée aux journaux est bien suffisante. Je continue de penser qu'elle est inutile. Les journaux peuvent rester où ils ont été créés. Leur rotation ne sera pas responsable de l'usure du SSD .
Cela ne doit quand même pas empêcher de regarder si des erreurs sont collectées si on en dispose.
D'autres remarques. On peut penser que lorsqu'on installe une LTS dans un ordinateur d'un particulier, l,O.S. a été suffisamment testé pour ne pas avoir de bug. Conserver un historique sur plusieurs mois me semble anormal. Les conserver en RAM est une chose qui ne me semble pas anormale. Je pense même que ne pas en avoir du tout n'est pas une stupidité si on ne regarde pas ce qui est produit! (Certzinbement une majorité de personnes)
On peut à tout instant changer le paramétrage du fichier de configuration et relancer le service si on décide d'installer installer un snap ou un appimage voir un deb qui ne fonctionne pas tellement bien et qu'on est testeur de ce logiciel.!!!
Pour l'autre problème de la collecte des vieux logs, on peut aussi modifier les fichiers de configuration pour les ventiler ailleurs que dans /var/log Voir document optimisation des SSD. Il y a aussi un fichier de paramétrage pour dire le nombre de rotations à conserver.
Conclusion. Si le répertoire /var/log dépasse 4 Go en taille, il faut regarder ailleurs que les log de systemd qui sont dans /var/log/systemd
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#68 Le 16/05/2020, à 18:50
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
alors en fait c'est bien l'inverse qu'il faut faire :
/data/LinuxData/var/log /var/log none bindcette fois c'est écris sur le HDD mais on a à nouveau le problème que j'avais avec la commande de geole, c'est à dire qu'il manque des fichiers et dossiers comme journal. c'est chiant...
Ne mélange pas tout
Si tu veux récupérer le passé, il faut d'abord le copier du SSD vers le HDD avant de binder.
Si tu veux aussi récupérer l'espace disque du SSD, il faut le supprimer après l'avoir copié sur le SSD avant de BINDER
et si tu ne veux pas perdre un seul message, il faut le faire avec le support d'installation.
Sinon les répertoires log/journal et log du HDD contiendront uniquement les nouveaux fichiers lorsqu'ils seront créés.
Dernière modification par geole (Le 16/05/2020, à 18:52)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#69 Le 16/05/2020, à 19:00
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Salut geole !
Pas la peine de tester l'inverse (voir les EDIT au dessus de ton message) ta solution marche, l'inverse non.
Il est donc clair qu'une seule partition dédiée aux journaux est bien suffisante. Je continue de penser qu'elle est inutile. Les journaux peuvent rester où ils ont été créés. Leur rotation ne sera pas responsable de l'usure du SSD .
Si je comprends bien tu me suggère d'empêcher la création des logs problématiques syslog et kern.log et d'abandonner cette histoire de déplacement vers une autre partition du dossier log...
Je pense que c'est ce que je vais faire si j'y arrive.
Pour une raison inconnue commenter les lignes associées comme tu me l'avais expliqué n'empêche pas la création de ces fichiers. Je vais retester mais je trouve ça bizarre.
Je vais faire un ou deux tests supplémentaires mais si ça ne marche pas je vais laisser tomber cette idée de déplacer ça... Je vais juste tenter de limiter la place prise.
D'autres remarques. On peut penser que lorsqu'on installe une LTS dans un ordinateur d'un particulier, l,O.S. a été suffisamment testé pour ne pas avoir de bug.
j'avoue que je ne pensais pas me retrouver face à 50go de logs sur une LTS...
Hors ligne
#70 Le 16/05/2020, à 19:11
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
OK, je déclare forfait là dessus.
Je vais regarder vos messages précédents sur la limitation de taille espérant que ça marche mieux. Déplacer /var/log est sans doute la chose la plus chiante que j'ai jamais faite sur Linux, je vais arrêter avant de devenir un Windowsien XD
Donc... Limiter la taille, regardons ça
Hors ligne
#71 Le 16/05/2020, à 19:18
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
MJ_Tistus a écrit :alors en fait c'est bien l'inverse qu'il faut faire :
/data/LinuxData/var/log /var/log none bindcette fois c'est écris sur le HDD mais on a à nouveau le problème que j'avais avec la commande de geole, c'est à dire qu'il manque des fichiers et dossiers comme journal. c'est chiant...
Ne mélange pas tout
Si tu veux récupérer le passé, il faut d'abord le copier du SSD vers le HDD avant de binder.
Si tu veux aussi récupérer l'espace disque du SSD, il faut le supprimer après l'avoir copié sur le SSD avant de BINDER
et si tu ne veux pas perdre un seul message, il faut le faire avec le support d'installation.
Sinon les répertoires log/journal et log du HDD contiendront uniquement les nouveaux fichiers lorsqu'ils seront créés.
Je n'avais pas vu ton message
Ah ok, je comprends ! Mais il n'y avait pas fichiers qui étaient absents et que tu trouvait étrange de ne pas voir ? Je pensais que ces fichiers que tu cherchais et qui n'étaient pas là auraient du être recréés, et que s'ils ne l'étaient pas c'est qu'il y avait un problème.
Hors ligne
#72 Le 16/05/2020, à 19:32
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
initialement, tu avais juste un problème technique à résoudre. Ne pas fabriquer les fichiers /var/log/syslog.
ou un problème fonctionnel de bug sur un logiciel qui faisait exploser cette collecte.
Tu as exploré une piste permettant d'en collecter ailleurs qu'à l'endroit prévu initialement. Il n'y a pas tellement de documentation claire qui explique les mélanges entre ces deux collectes.
Comme je l'ai dit et vérifié, la collecte native ne peut dépasser 4 GO. Mais la viellle collecte est basée sur autre chose. Moko138 connaît mieux.
Voici son premier fichier de paramétrage voir paragraphe https://doc.ubuntu-fr.org/ssd_solid_sta … u_logiciel
Donne le retour de ces commandes pour voir si cest bien déactivé
head -13 /etc/rsyslog.d/50-default.confls -ls /var/log/syslog*
ls -ls /var/log/kern*Tu y noteras qu'il y a en clair l'endroit où stocker chaque type de collecte. Il est nettement plus simple de le modifier que de faire des liens.
Je recherche le second fichier d'épuration.
Voici déjà sa documentation à lire https://doc.ubuntu-fr.org/logrotate
En regardant, le contenu que j'ai actuellement en version 20.04, je sens que je ne vais rien comprendre. Sinon en regardant encore ailleurs
cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly
# use the adm group by default, since this is the owning group
# of /var/log/syslog.
su root adm
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
#dateext
# uncomment this if you want your log files compressed
#compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# system-specific logs may be also be configured here.(L'apéro m'attend!)
Dernière modification par geole (Le 16/05/2020, à 19:42)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#73 Le 16/05/2020, à 19:47
- MJ_Tistus
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
head -13 /etc/rsyslog.d/50-default.conf# Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
#################### *.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
################### kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.logls -ls /var/log/syslog*alors ça tombe mal pour cette commande, je viens de supprimer les anciens fichiers syslog (syslog.1 syslog.2.gz ... syslog.7.gz si je me souviens bien) afin de voir s’ils sont recréés ou pas.
0 -rw-r----- 1 syslog adm 0 mai 16 15:58 /var/log/syslogls -ls /var/log/kern* 552 -rw-r----- 1 syslog adm 562570 mai 13 18:26 /var/log/kern.log
1244 -rw-r----- 1 syslog adm 1270559 mai 12 16:29 /var/log/kern.log.1Tu y noteras qu'il y a en clair l'endroit où stocker chaque type de collecte. Il est nettement plus simple de le modifier que de faire des liens.
Ah ba oui ! XD
Voici déjà sa documentation à lire https://doc.ubuntu-fr.org/logrotate
(L'apéro m'attend!)
d'acc, merci
Bon apéro ! ^^
Hors ligne
#74 Le 17/05/2020, à 12:16
- geole
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
ls -ls /var/log/kern*552 -rw-r----- 1 syslog adm 562570 mai 13 18:26 /var/log/kern.log 1244 -rw-r----- 1 syslog adm 1270559 mai 12 16:29 /var/log/kern.log.1
Bonjour
La modification semble bonne
Tu as maintenant deux syslog qui ont une taille toute petite Je pense que les futurs kernlog auront aussi une très petite taille
Il faudrait donc attendre l'arrivée de la version 20.04 pour que leur taille soit nulle Après avoir corrigé le fichier de configuration!
a@a:/var/log$ ls -ls kern*
0 -rw-r----- 1 syslog adm 0 avril 26 10:31 kern.log
112 -rw-r----- 1 syslog adm 114342 avril 18 16:24 kern.log.1
a@a:/var/log$ ls -ls syslog*
0 -rw-r----- 1 syslog adm 0 avril 20 10:45 syslog
528 -rw-r----- 1 syslog adm 536985 avril 18 16:24 syslog.1
a@a:/var/log$ Dernière modification par geole (Le 17/05/2020, à 12:19)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#75 Le 17/05/2020, à 17:44
- moko138
Re : Ubuntu 20.04 démarrage impossible (SEV: failed), /var de 60go
Salut,
J'ai peu de temps, donc très rapidement, j'interviens sur un seul point, le journal.
MJ_Tistus,
Puisque tu veux la journalisation, c'est à toi de créer /data/LinuxData/tistus/var/log/journal/
Et comme il a des droits quelque peu tarabiscotés, si j'en crois ton premier message :
drwxr-sr-x+ 3 root systemd-journal 4,0K avril 23 21:39 journal
et que je ne sais pas les recréer, on va éviter le simple sudo mkdir -v,
et tu vas tout simplement recopier l'original :
sudo cp -av /var/log/journal /data/LinuxData/tistus/var/log/C'est tout ! (Enfin: peut-être faudra-t-il redémarrer ensuite).
Explication :
L'absence du répertoire journal/ désactive la journalisation.
Donc quand tu montes /var/log sur un répertoire ne contenant pas déjà journal/, tu empêches la journalisation. Donc le système n'a aucune raison de recréer le répertoire manquant.
Mais si le système constate la présence du répertoire, il va réactiver la journalisation.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne