Apt-get E: You don't have enough free space

Bonjour à tous,

Je me suis commandé un serveur dédié sur kimsufi (non ce n’est pas un placement de produit) :wink: afin de me familiariser avec le monde linux, les lignes de commandes … etc et comprendre comment ça marche.

Seulement voilà, je me suis installé un nextcloud en suivant ce tutoriel https://howto.wared.fr/ubuntu-installation-nextcloud-nginx/

Tout a bien fonctionné jusqu’à il y a quelques jours où lorsque j’ai souhaité effectuer la commande, pourtant d’une simplicité extrême, “apt-get update” et son acolyte “apt-get upgrade” j’ai le message d’erreur :

root:~# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libsystemd0 libudev1 ovhkernel-4.9-xxxx-std-ipv6-image systemd systemd-sysv udev
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 14.6 MB of archives.
After this operation, 0 B of additional disk space will be used.
**E: You don't have enough free space in /var/cache/apt/archives/**.

C’est alors que j’ai effectué quelques recherches sur internet, y compris sur ce forum, où j’ai trouvé la commande à effectuer df -H pour connaitre l’état “des disques” :

Filesystem      Size  Used Avail Use% Mounted on
udev            8.4G     0  8.4G   0% /dev
tmpfs           1.7G  179M  1.6G  11% /run
**/dev/md3         21G   20G   35M 100% /**
tmpfs           8.5G     0  8.5G   0% /dev/shm
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           8.5G     0  8.5G   0% /sys/fs/cgroup
/dev/md2        511M   37M  444M   8% /boot
/dev/md4        2.0T   38G  1.9T   3% /home

Bien, à présent j’ai compris que j’avais dépassé les bornes et j’ai donc souhaité “cleaner” tout ça afin de pouvoir faire mon apt-get update & upgrade.

J’ai cherché et je suis tombé sur la commande “apt-get clean”, “apt-get autoclean”, qui n’ont donné aucun résultat satisfaisant…
J’ai toujours 100% d’occupation sur /dev/md3. Je pense que mon problème vient d’ici, car tous les autres on voit clairement de l’espace disponible.
J’ai souhaité voir ce qu’il se cachait dans ces archives, c’est alors que j’ai tapé dans mon terminal :
cd /var/cache/apt/archives/ !
Là, surprise ! Je vois deux dossiers aux noms respectifs “lock” et “partial”. Cependant, en entrant dans ces derniers et en faisant un petit coup de “ls”, rien ne s’affiche.

Je vous avoue être quelque peut perdu et c’est dans cette démarche que je viens solliciter vos âmes charitables. Je vous remercie par avance de toutes vos réponses,

Amicalement,
LM

Il faut chercher ailleurs.

du -xhd1 / | sort -h

A part ça, qui a fait ce partitionnement discutable ?

Merci pour ta réponse, PascalHambourg !

En faisant du -xhd1 / | sort -h

4.0K	/lib64
4.0K	/mnt
4.0K	/opt
4.0K	/srv
8.0K	/media
80K	/root
5.6M	/etc
12M	/bin
21M	/sbin
46M	/lib
562M	/var
710M	/usr
17G	/tmp
19G	/

Pour répondre à ta question : c’est OVH lui même (kimsufi au moment de la commande)

Il doit y avoir des choses à nettoyer dans /tmp.

du -xhd1 /tmp | sort -h

Oui, surment… En faisant un “ls” dans /tmp
J’ai énormement de phpmYuA5V

… ?

Va y franco.
Un bête rm -rf /tmp/* (ne pas oublier l’* à la fin surtout) va te faire gagner 19Go.
Ca va pêut être supprimmer des verrous ou des trucs comme ça ce qui peut faire planter certains services actifs, mais ils n’ont de validité que jusqu’au reboot, donc aprés, tu rebootes, et c’est marre, tu auras tes 19Go.
Pour éviter que ça ne recommence, tu peux monter un tmpfs sur /tmp genre de 512Mo au prix d’une part de ta RAM pour limiter l’utilisation de /tmp à 512Mo.

Ou bien récupèrer de la place d’une autre de tes partitions pour y créer une partition /tmp autonome, aussi.

Hum … Merci pour ta réponse mais avant d’effectuer cette commande, ceci ne va-t-il pas supprimer des fichiers téléversés via mon nextcloud ?
Normalement, je l’ai paramètré pour verser les fichiers dans le /home (vendu pour 2TO).

?
Merci :slight_smile:

Bon, c’est fait. Je fais présentement le reboot

Tu peux vérifier, mais si tu l’as configuré comme ça, je ne vois pas pourquoi il les aurait mis dans tmp.

/tmp est censé ne contenir que des fichiers temporaires qui n’ont pas besoin de persister après un redémarrage. Dans le cas contraire, il y a une erreur de configuration quelque part.

Pour un contenu actuel de 19 Go ? Ça ne va pas craquer un peu ?

C’est ce que j’allais dire: il faut comprendre pourquoi c’est monté à 19Go, c’est anormal.
La quantité de phpmachin est une piste, il y a peut être un truc à débuguer sur la config.

Sur mon dédié, qui je l’avoue est un peu trop performant pour mes besoins, il n’y a que Nginx et Nextcloud pour le moment. (Nextcloud tournant sur Nginx).

Vous pensez qu’nginx m’aurait mangé 19GO dans le /tmp ?

Coté partition j’ai laissé faire l’installation (via le manager)

Pour information, c’est le KS11 que j’ai commandé

Je ne connais pas du tout le fonctionnement d’Nginx.
Si possible j’aurais utilisé LVM pour plus de souplesse dans la gestion des volumes.

Elle est un peu pourrie, il faut prévoir 40Go mini sur / pour être large tranquille en installant plein de trucs, si /var n’est pas séparée.
Mais bon, là tu as une petite install qui prend 3Go si je ne me trompe, donc tes 20Go de / auraient du être suffisant s’il n’y avait pas eu ce probléme de /

Et sinon, je viens de découvrir bleachbit, qui fait un nettoyage plus large que juste /tmp

Oups… Je crois que j’ai supprimé un truc qu’il ne fallait pas ?

WARNING: missing /lib/modules/4.9.153-xxxx-std-ipv6-64
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.9.153-xxxx-std-ipv6-64: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open /var/tmp/mkinitramfs_iRrgEb/lib/modules/4.9.153-xxxx-std-ipv6-64/modules.order: No such file or directory
depmod: WARNING: could not open /var/tmp/mkinitramfs_iRrgEb/lib/modules/4.9.153-xxxx-std-ipv6-64/modules.builtin: No such file or directory

Je ne suis pas sur que ça vienne de nginx directement, ça sent plutôt l’élément de config du host nextcloud qui génére les fichiers temporaires de php sous un certain user, puis tente de les nettoyer avec un autre:
avec le sticky bit qu’il y a sur /tmp, le nettoyage ne se fait pas et les fichiers s’accumulent.

C’est quoi cette version de noyau ?
Ca ne me semble pas lié à ton nettoyage, plutôt à une mauvaise install d’un noyau sur laquelle la machine n’avait jamais reboté jusque là.
Si tu as la main, fais un réinstall du noyau concerné avec apt et rebootes.

Le noyau d’OVH ne serait pas un noyau sans modules ?

Excellente remarque.
J’avais oublié qu’OVH fonctionnait avec un noyau custom.