#51 Le 20/10/2019, à 16:17
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Le Pedro a écrit :pierre@pierre-System-Product-Name:~$ echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo -e "\nNoyau courant : $(uname -mr)" ii linux-headers-generic-lts-quantal 3.13.0.170.181 amd64 ii linux-image-generic-lts-trusty 3.13.0.170.181 amd64 ii linux-image-generic-lts-quantal 3.13.0.170.181 amd64 ii linux-generic-lts-trusty 3.13.0.170.181 amd64 ii linux-generic-lts-quantal 3.13.0.170.181 amd64
Ces paquets peuvent être désinstallés.
comment je fais ?
Hors ligne
#52 Le 20/10/2019, à 16:20
- moko138
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Montre
sudo apt-get remove --purge linux-headers-generic-lts-quantal linux-image-generic-lts-trusty linux-image-generic-lts-quantal linux-generic-lts-trusty linux-generic-lts-quantal ; echo ; df -Th | grep -Ev "udev|tmpfs|loop"
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#53 Le 20/10/2019, à 16:27
- nany
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Le résultat est le même qu'au message #47
C’est normal, ça fait la même chose mais avec une seule commande au lieu de deux.
C’était pour signaler à moko138 (et à tous ceux qui liront ce fil) qu’il existe l’option -x pour df qui permet d’éviter de se servir de grep.
Hors ligne
#54 Le 20/10/2019, à 16:44
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
@ nany : ok
@ moko138 :
pierre@pierre-System-Product-Name:~$ sudo apt-get remove --purge linux-headers-generic-lts-quantal linux-image-generic-lts-trusty linux-image-generic-lts-quantal linux-generic-lts-trusty linux-generic-lts-quantal ; echo ; df -Th | grep -Ev "udev|tmpfs|loop"
[sudo] Mot de passe de pierre :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
linux-generic-lts-quantal* linux-generic-lts-trusty*
linux-headers-generic-lts-quantal* linux-image-generic-lts-quantal*
linux-image-generic-lts-trusty*
0 mis à jour, 0 nouvellement installés, 5 à enlever et 0 non mis à jour.
Après cette opération, 164 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] O
(Lecture de la base de données... 254888 fichiers et répertoires déjà installés.)
Suppression de linux-generic-lts-quantal (3.13.0.170.181) ...
Suppression de linux-generic-lts-trusty (3.13.0.170.181) ...
Suppression de linux-headers-generic-lts-quantal (3.13.0.170.181) ...
Suppression de linux-image-generic-lts-quantal (3.13.0.170.181) ...
Suppression de linux-image-generic-lts-trusty (3.13.0.170.181) ...
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
/dev/sda5 ext4 425G 375G 29G 94% /
pierre@pierre-System-Product-Name:~$
Hors ligne
#55 Le 20/10/2019, à 21:42
- moko138
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Le Pedro : impeccable !
nany : merci du tuyau !
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#56 Le 21/10/2019, à 17:54
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Le problème est de retour aujourd'hui
Hors ligne
#57 Le 21/10/2019, à 18:51
- cqfd93
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Bonjour,
Juste curieuse, c'est quoi cet énorme fichier core qu'on voit dans le retour de ls -la / du message #36 ?
− cqfd93 −
Hors ligne
#58 Le 21/10/2019, à 19:15
- melixgaro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Quand le problème se produit (et avant de redémarrer puisque cette opération semble recréer la place), il faudrait que tu passes les commandes de moko à base de du pour identifier les dossiers qui grossissent. Quand tu vois le problème venir, il faudrait que tu fasses un
top
qui pourrait mettre en évidence un processus actif, responsable du remplissage du disque.
Linux depuis ~2007. Xubuntu seulement.
Hors ligne
#59 Le 21/10/2019, à 20:46
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
pierre@pierre-System-Product-Name:~$ top
top - 20:46:33 up 2:04, 1 user, load average: 0,79, 0,30, 0,15
Tâches: 219 total, 2 en cours, 217 en veille, 0 arrêté, 0 zombie
%Cpu(s): 14,8 ut, 3,6 sy, 0,0 ni, 59,9 id, 21,5 wa, 0,0 hi, 0,2 si, 0,0 st
KiB Mem : 9913028 total, 4990068 libr, 1454628 util, 3468332 tamp/cache
KiB Éch: 1764348 total, 1764348 libr, 0 util. 7965956 dispo Mem
PID UTIL. PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM.
2320 pierre 20 0 2442716 411052 117548 R 66,1 4,1 0:34.10 thunderbird
517 root 20 0 108424 14832 8844 S 4,3 0,1 5:48.03 plymouthd
1056 root 20 0 443332 85352 72616 S 1,3 0,9 0:19.26 Xorg
2464 pierre 20 0 2650004 162496 123368 S 1,0 1,6 1:19.30 Web Content
3438 pierre 20 0 665944 37980 30292 S 1,0 0,4 0:00.54 gnome-term+
1898 pierre 20 0 1211488 103520 60500 S 0,7 1,0 0:40.31 compiz
2306 pierre 20 0 3223964 332860 164088 S 0,7 3,4 3:00.00 firefox
3457 pierre 20 0 41944 3896 3268 R 0,7 0,0 0:00.11 top
1454 pierre 20 0 479032 31256 25880 S 0,3 0,3 0:00.35 ibus-ui-gt+
2335 pierre 20 0 2206672 84748 34412 S 0,3 0,9 0:05.01 transmissi+
1 root 20 0 119620 5852 4092 S 0,0 0,1 0:02.85 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:00.01 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:+
6 root 20 0 0 0 0 S 0,0 0,0 0:00.46 kworker/u8+
Hors ligne
#60 Le 21/10/2019, à 20:55
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Quand le problème se produit (et avant de redémarrer puisque cette opération semble recréer la place), il faudrait que tu passes les commandes de moko à base de du pour identifier les dossiers qui grossissent.
Ces commandes-là ?
sudo du -xam --max-depth=1 / 2>/dev/null | sort -h | tail -7 ; echo ; sudo du -sm /snap
du -am --max-depth=1 ~ | sort -h | tail -7
sudo du -am --max-depth=1 /var 2>/dev/null | sort -h | tail -7 ; echo ; sudo du -sm /var/lib/snapd
sudo du -am --max-depth=1 /var/log | sort -h | tail -7
sudo du -am --max-depth=1 /root | sort -h | tail
sudo du -am --max-depth=1 ~/.cache | sort -h | tail
sudo du -a --max-depth=2 /root/.local | sort -h | tail -20
sudo du -a --max-depth=3 /root | sort -h | tail -20
Hors ligne
#61 Le 21/10/2019, à 21:06
- melixgaro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Je pense que c'est celle-là la plus intéressante
du -am --max-depth=1 ~ | sort -h | tail -7
T'es sûr que ce n'est pas transmission le coupable ?
Linux depuis ~2007. Xubuntu seulement.
Hors ligne
#62 Le 21/10/2019, à 23:51
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
je ne suis sûr de rien, et c'est vrai que Transmission est ouvert en permanence chez moi...
Hors ligne
#63 Le 22/10/2019, à 11:50
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Ce matin, je récupère de nouveau mes un peu plus de 30 Gio dispos...
Transmission tourne...
Bonjour,
Juste curieuse, c'est quoi cet énorme fichier core qu'on voit dans le retour de ls -la / du message #36 ?
Je n'en ai aucune idée...
Juste pour rappel, je donne l'extrait du retour de ls -la qui correspond au fameux fichier :
-rw------- 1 root root 10223616 sept. 27 00:39 core
Dernière modification par Le Pedro (Le 22/10/2019, à 11:51)
Hors ligne
#64 Le 22/10/2019, à 11:59
- moko138
Re : pb unity -> .cache/upstart/unity7.log monstrueux
melixgaro a écrit :Quand le problème se produit (et avant de redémarrer puisque cette opération semble recréer la place), il faudrait que tu passes les commandes de moko à base de du pour identifier les dossiers qui grossissent.
Ces commandes-là ?
(...)
Il serait plus utile que tu fournisses les retours de commandes.
Parce que pas de retour = pas d'information.
Et en l'absence d'information, les aidants ne peuvent rien pour toi.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#65 Le 22/10/2019, à 12:14
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
On est bien d'accord, mais melixgaro avait écrit "quand le problème se produit", or le problème s'était produit. Si j'ai bien compris (mais je me trompe peut-être car les retours que je poste ici demeurent assez obscurs pour moi), ces commandes (et plus particulièrement celle qui est citée au message #61) permettent de détecter les fichiers qui "grossissent" : si je n'ai plus d'espace libre sur le DD, c'est trop tard pour donner le retour des commandes, non ?
Hors ligne
#66 Le 22/10/2019, à 12:51
- xinu
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Bonjour,
Quand tu n'as plus de place, donne le retour de la commande suivante :
sudo du -sch .[!.]* * |sort -h
Je soupçonne thunderbird de mouliner dans la semoule...
Asus PM8H61-MX USB3 Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz DDR3 8Go
Ubuntu 16.04 LTS - ESM 64 bits. Bureau Unity. Ubuntu 20.04 LTS 64 bits . Gnome 3.36.8
Hors ligne
#67 Le 22/10/2019, à 13:01
- moko138
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Non.
En gros, "du" mesure le remplissage de la baignoire, pas le débit du robinet.
(C'est donc trop tard quand l'espace libre est redevenu normal.)
Et puisque tu dis que le remplissage peut redevenir normal après redémarrage, merci d'ajouter à la liste
sudo du -ah --max-depth=1 /tmp | sort -h | tail -5
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#68 Le 22/10/2019, à 13:02
- ylag
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Salut,
@cqfd93: «Juste curieuse, c'est quoi cet énorme fichier core qu'on voit dans le retour de ls -la / du message #36 ?»
C'est pas un "core dump" créé lors de plantage d'applications?
Au cas où ce serait pertinent, voir cette page (en anglais, par contre) à ce sujet:
understand-and-configure-core-dumps-work-on-linux
Pour info, sur ma 18.04 de base, j'ai ceci par défaut:
yvan@yvan-maison:~$ sysctl fs.suid_dumpable
fs.suid_dumpable = 0
yvan@yvan-maison:~$
...qui signifierait que la création de ce fichier est désactivée sur mon système?
Il semblerait que la taille de ces fichiers "dump" puisse se gérer avec la commande ulimit ?
?
Dernière modification par ylag (Le 22/10/2019, à 13:11)
Hors ligne
#69 Le 22/10/2019, à 13:09
- Le Pedro
Re : pb unity -> .cache/upstart/unity7.log monstrueux
@ moko138 : on est bien d'accord que j'attends, puisque aujourd'hui, le pb ne se présente pas ?
@ ylag : j'ai renoncé à lire l'article en lien, mon niveau d'anglais ne me le permet pas. En revanche, je sais que depuis mon passage à ubuntu 16.04 (très récent), j'ai plusieurs plantage d'applis notamment au démarrage. Ça m'avait déjà fait ça lors du passage à la 14.04. Mais je ne sais pas quelles applis plantent... De même, depuis quelques temps, il ne détecte plus la bonne config graphique au démarrage, et part systématiquement en "low-graphic mode", il faut toujours que je repasse la bonne résolution manuellement.
Mais : le pb qui nous occupe ici était déjà présent avant mon passage à la 16.04, il est par contre de plus en plus fréquent/récurrent (quasi 1 jour sur 2 en ce moment...).
Dernière modification par Le Pedro (Le 22/10/2019, à 13:09)
Hors ligne
#70 Le 22/10/2019, à 13:15
- ylag
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Salut,
@ ylag : j'ai renoncé à lire l'article en lien, mon niveau d'anglais ne me le permet pas.
Désolé pour l'Anglais; je n'arrive pas à trouver l'équivalent en Français.
La taille maximale du fichier core pourrait se configurer dans le fichier /etc/security/limits.conf ?
Note: Il y a peut-être un problème matériel sous-jacent sur ta machine...?
A+
Dernière modification par ylag (Le 22/10/2019, à 13:36)
Hors ligne
#71 Le 22/10/2019, à 13:23
- moko138
Re : pb unity -> .cache/upstart/unity7.log monstrueux
@ moko138 : on est bien d'accord que j'attends, puisque aujourd'hui, le pb ne se présente pas ?
Oui, et melixgaro avait été explicite :
Quand le problème se produit (et avant de redémarrer (...))
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#72 Le 22/10/2019, à 13:46
- ylag
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Salut,
Est-ce que la désactivation du service apport pourrait prévenir la création de ces fichiers « core »?
sudo systemctl disable apport.service
...puis redémarrage.
?
Hors ligne
#73 Le 22/10/2019, à 13:52
- moko138
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Je ne vois pas pourquoi le service apport - qu'il est toujours bon de désactiver, quand on ne teste pas une pré-version d'Ubuntu - créerait des fichiers à la racine.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#74 Le 22/10/2019, à 13:53
- cqfd93
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Bonjour,
J'ai trouvé ça (en français) : Limiter la taille des fichiers CORE.
− cqfd93 −
Hors ligne
#75 Le 22/10/2019, à 14:00
- inbox
Re : pb unity -> .cache/upstart/unity7.log monstrueux
Je ne vois pas pourquoi le service apport - qu'il est toujours bon de désactiver, quand on ne teste pas une pré-version d'Ubuntu - créerait des fichiers à la racine.
Et avec le compte root.
Un problème résolu ? Indiquez le en modifiant le titre du sujet.
Hors ligne