Ubuntu-fr

Le Pedro

Re : pb unity -> .cache/upstart/unity7.log monstrueux

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 ?

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

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.

---

Le mot de passe sudo ne s'affiche pas - Comment bien utiliser les balises BBcode
Retour aux sources.
Urtikan.net - https://youtu.be/2uznaTjvb7I
LIBRARIES ARE NOT BOOK-STORES!

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:~$ 

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

Le Pedro

Re : pb unity -> .cache/upstart/unity7.log monstrueux

Le problème est de retour aujourd'hui

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 −

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.

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+ 

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

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.

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...

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)

moko138

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à ?
(...)

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

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 ?

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

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

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)

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)

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)

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

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.

?

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

cqfd93

Re : pb unity -> .cache/upstart/unity7.log monstrueux

Bonjour,

J'ai trouvé ça (en français) : Limiter la taille des fichiers CORE.

---

− cqfd93 −

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.