Est-il sûr de supprimer manuellement le contenu / var / cache / apt?

21

Sur un système embarqué avec un espace disque très limité, j'ai le dossier /var/cache/aptplein avec environ 700 Mo srcpkgcache.bin.*et quelques gros *.binfichiers.

Jouer sudo apt-get cleann'a pas fait de différence visible.

Est-il sûr de supprimer manuellement ces *.bin*fichiers?

apt apt-cache

— ysap
source

6

Depuis Ubuntu 14.04, il est parfaitement sûr de supprimer les *.binfichiers dans ledit dossier - en supposant qu'aucun processus lié à apt n'est en cours d'exécution. La prochaine apt-get updaterégénérera les *.binfichiers. Cette question ne concerne décidément pas les fichiers /var/cache/apt/archives, mais les fichiers /var/cache/apt/*.bin. Grande différence. Les premiers peuvent être nettoyés par émission apt-get clean, les seconds doivent être retirés manuellement. Il est clair que ceux qui votent pour clore la question ne l'ont pas lu correctement. Malheureusement, je ne peux pas voter pour rouvrir après avoir accordé une partie de mon représentant en primes.

— 0xC0000022L

3

Ce n'est pas un doublon. La réponse liée concerne le sous-répertoire à l' archivesintérieur /var/cache/apt/, celui-ci concerne les *.bin*fichiers.

— Olaf Dietsche

1

Duplication possible de Supprimer les fichiers de / var / cache / apt (PAS d'archives)

— Eliah Kagan

11

Pas vraiment. Ces fichiers aident votre système à déterminer ce qui est disponible et ce qui ne l'est pas. Vider ce répertoire entraînera un système apt-get cassé. Voici quelques conseils.

Tout d'abord, le nettoyage automatique

ajouter un

DPkg::Post-Invoke { "apt-get clean"; };

à la fin de /etc/apt/apt.conf. Cela rendra les processus apt et dpkg plus longs, mais fera en sorte que votre répertoire de cache soit toujours propre.

Ensuite, supprimez les archives

Commencez par supprimer et désactiver toutes les archives sources (que vous n'utilisez pas). Sur un système embarqué, vous n'en avez probablement pas besoin. Supprimez ensuite toutes les archives qui ne sont pas utilisées. Vous pouvez exécuter apt-cache policypour comprendre de quel repo provient un paquet si vous n'êtes pas sûr.

Plus Suppression d'archives

Certains PPA sont horribles d'avoir un grand nombre de packages en eux lorsque vous n'en avez besoin que de 1 ou 2. Essayez de désactiver ces PPA et d'installer simplement les fichiers deb manuellement. Vous économisez de l'espace dans ces cas, mais vous perdez la mise à jour automatique. Gardez à l'esprit que dpkg gérera les dépendances, vous pouvez donc toujours installer thing-with-tons-of-deps.deb puis exécuter apt-get -f installpour récupérer les dépendances.

Réponse totalement extrême 1

Parce qu'il s'agissait d'un système embarqué, 90% des référentiels principaux ne vous serviront à rien. Pour gérer cela, vous pouvez exécuter votre propre serveur repo apt-get Voir ce lien . Ce n'est pas facile et c'est un PIA pour une seule machine. Mais si vous avez plusieurs de ces machines, cela en vaut la peine. (Votre serveur de repo apt peut héberger juste un sous-ensemble de packages que vous utilisez réellement. Vous n'avez pas besoin de refléter le tout)

Réponse totalement extrême 2

Si l'espace est vraiment important, vous pouvez désactiver apt tous ensemble et revenir à l'installation manuelle via dpkg. J'ai dû le faire sur plusieurs systèmes embarqués. Cela fonctionne, mais c'est un cauchemar d'administrateur.

— coteyr
source

C'est une excellente réponse (en particulier les réponses totalement extrêmes) mais /etc/apt/apt.conf n'existe plus dans Ubuntu 14.04. Quelle est la meilleure pratique actuelle?

— zachaysan

1

Créez le fichier s'il n'existe pas. Il sera toujours lu.

— coteyr

5

S'il vous plaît, pourquoi écrivez-vous qu'il n'est pas sûr de supprimer les *.binfichiers? Toute exécution de apt-get updaterégénérera ces fichiers à partir de zéro (testé). Par exemple, mon cas d'utilisation est que je souhaite créer des modèles de conteneur LXC et que je souhaite supprimer l'archive autant que possible. Je ne vois aucune raison pour laquelle c'est dangereux. Et votre réponse n'indique aucune raison, indique simplement qu'elle n'est pas sûre. Testé qu'il est parfaitement sûr sur Ubuntu 14.04.

— 0xC0000022L

1

Vous dites que l'inclusion apt-cache cleandans un appel dpkg résultera en un cache plus propre, mais l'utilisateur dit qu'il apt-cache cleann'a rien nettoyé pour eux. De plus, votre réponse est totalement erronée car dpkg n'utilise pas de /var/cache/apt/*contenu pour être informé des statistiques du package.

— Anwar

1

La page de manuel apt-get décrit clairement la fonction de cleanas * clean efface le référentiel local des fichiers de package récupérés. Il supprime tout sauf le fichier de verrouillage de / var / cache / apt / archives / et /var/cache/apt/archives/partial/.* S'il est dangereux, il n'y aurait pas une telle fonction à nettoyer.

— Anwar

3

Vous pouvez bien sûr supprimer pkgcache.binet srcpkgcache.binrien ne se passe. Il suffit de courir apt-get updatepour les recréer.

— Tomas M
source

... et est-ce vrai indépendamment de la suppression des .debfichiers?

— einpoklum - réintègre Monica le

1

Gardez le pkgcache.binet srcpkgcache.bin, vous pouvez supprimer les autres en toute sécurité. Ne touchez pas aux répertoires!

— Frantique
source

OK merci. J'ai temporairement déplacé les *bin.*fichiers vers un dossier de sauvegarde. Cependant, pourquoi apt-get gère-t-il le cache à l' intérieur du cache? Un répertoire de cache doit être un stockage temporaire par nature.

— ysap

Ce problème est déjà signalé. :) Voir ici

— Frantique

Vous pouvez bien sûr supprimer pkgcache.bin et srcpkgcache.bin, rien ne se passe. la mise à jour apt-get les recrée.

— Tomas M

0

Vous pouvez bien sûr créer un partage NFS (système de fichiers réseau) pour cela. Laissez ces fichiers sur un serveur et montez le partage uniquement lorsque vous souhaitez mettre à jour / installer des packages. Dans les environnements embarqués, l'installation sera généralement relativement statique de toute façon.

sshfs est une autre bonne option, est beaucoup plus facile à configurer (nécessite essentiellement SSH qui est standard), mais il a plus de surcharge (plus lent).

— jippie
source

Cela devrait techniquement fonctionner, sauf que vous n'avez pas le contrôle total du moment où apt s'exécute. Si vous utilisez quelque chose comme ça, vous devez vous assurer que vous désactivez les tâches "automatisées" comme les tâches cron qui exécutent la mise à jour apt-get.

— coteyr