Apakah aman untuk menghapus konten / var / cache / apt secara manual?


21

Pada sistem tertanam dengan ruang disk yang sangat terbatas, saya memiliki folder /var/cache/aptpenuh dengan sekitar 700MB srcpkgcache.bin.*dan beberapa *.binfile besar .

Pertunjukan sudo apt-get cleantidak membuat perbedaan yang terlihat.

Apakah aman untuk menghapus *.bin*file - file ini secara manual ?


6
Pada Ubuntu 14.04 sangat aman untuk menghapus *.binfile di folder tersebut - dengan asumsi tidak ada proses terkait apt sedang berjalan. Selanjutnya apt-get updateakan membuat ulang *.binfile. Pertanyaan ini jelas bukan tentang file dalam /var/cache/apt/archives, tetapi file /var/cache/apt/*.bin. Perbedaan besar. Yang pertama dapat dibersihkan dengan mengeluarkan apt-get clean, yang terakhir harus dihapus secara manual. Jelas mereka yang memilih untuk menutup pertanyaan belum membaca pertanyaan dengan benar. Sayangnya saya tidak bisa memilih untuk membuka kembali setelah memberikan beberapa perwakilan saya dalam hadiah.
0xC0000022L

3
Ini bukan duplikat. Jawaban yang ditautkan adalah tentang subdirektori di archivesdalam /var/cache/apt/, ini tentang *.bin*file.
Olaf Dietsche

Jawaban:


11

Tidak juga. File-file itu membantu sistem Anda menentukan apa yang tersedia dan apa yang tidak. Mengosongkan direktori itu akan menghasilkan sistem apt-get yang rusak. Berikut ini beberapa tips.

Pertama, otomatis bersih

tambah sebuah

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

sampai akhir /etc/apt/apt.conf. Ini akan membuat proses apt dan dpkg membutuhkan waktu lebih lama, tetapi akan membuatnya jadi direktori cache Anda selalu bersih.

Selanjutnya, Hapus arsip

Mulailah dengan menghapus dan menonaktifkan semua arsip sumber (yang tidak Anda gunakan). Pada sistem tertanam Anda kemungkinan besar tidak membutuhkannya. Selanjutnya hapus semua arsip yang tidak digunakan. Anda dapat menjalankan apt-cache policyuntuk mencari tahu dari mana repo paket berasal jika Anda tidak yakin.

Lebih Banyak Penghapusan arsip

Beberapa PPA mengerikan tentang memiliki sejumlah besar paket di dalamnya ketika Anda hanya membutuhkan 1 atau 2. Coba nonaktifkan PPA tersebut dan cukup instal file deb secara manual. Anda menghemat ruang dalam kasus-kasus itu, tetapi Anda kehilangan pembaruan otomatis. Ingatlah bahwa dpkg akan menangani dependensi, jadi Anda masih dapat menginstal hal-with-ton-of-deps.deb kemudian jalankan apt-get -f installuntuk mengambil dependensinya.

Jawaban Sangat Ekstrem 1

Karena berbicara tentang sistem tertanam, 90% dari repo utama tidak akan ada gunanya bagimu. Untuk menangani ini, Anda dapat menjalankan server repo apt-get Anda sendiri. Lihat tautan ini . Itu tidak mudah, dan ini adalah PIA untuk hanya satu mesin. Tetapi jika Anda memiliki beberapa mesin ini, itu sangat berharga. (Anda apt server repo dapat meng-host hanya sebagian dari paket yang benar-benar Anda gunakan. Anda tidak perlu mencerminkan semuanya)

Jawaban Sangat Ekstrem 2

Jika ruang benar-benar sebesar masalah, maka Anda dapat menonaktifkan apt all together dan kembali menginstal secara manual melalui dpkg. Saya harus melakukan ini pada beberapa sistem embedded. Berhasil, tetapi ini adalah mimpi buruk admin.


Ini adalah jawaban yang bagus (terutama yang benar-benar ekstrem) tetapi /etc/apt/apt.conf tidak ada lagi di Ubuntu 14.04. Apa praktik terbaik saat ini?
zachaysan

1
Pertama buat file jika tidak ada. Itu masih akan dibaca.
coteyr

5
Tolong, mengapa Anda menulis itu tidak aman untuk menghapus *.binfile? Setiap menjalankan apt-get updateakan meregenerasi file-file itu dari awal (diuji). Sebagai contoh kasus penggunaan saya adalah bahwa saya ingin membuat templat wadah LXC dan ingin menghapus arsip sebanyak mungkin. Saya tidak bisa melihat alasan mengapa itu tidak aman. Dan jawaban Anda tidak menunjukkan alasan, hanya menyatakan bahwa itu tidak aman. Diuji bahwa sangat aman di Ubuntu 14.04.
0xC0000022L

1
Anda mengatakan memasukkan apt-cache cleanpanggilan dpkg akan menghasilkan cache yang lebih bersih, tetapi pengguna mengatakan apt-cache cleantidak membersihkan apa pun untuk mereka. Juga jawaban Anda benar - benar salah karena dpkg tidak menggunakan /var/cache/apt/*konten untuk mendapat informasi tentang statistik paket.
Anwar

1
Halaman apt-get manpage dengan jelas menjelaskan fungsi cleansebagai * clean menghapus repositori lokal dari file paket yang diambil. Ini menghapus semuanya kecuali file kunci dari / var / cache / apt / arsip / dan /var/cache/apt/archives/partial/.* Jika berbahaya, tidak akan ada fungsi seperti itu untuk dibersihkan.
Anwar

3

Anda tentu saja dapat menghapus pkgcache.bindan srcpkgcache.bin, tidak ada yang terjadi. Jalankan saja apt-get updateuntuk membuatnya kembali.


... dan apakah ini benar, terlepas dari penghapusan .debfile?
einpoklum - mengembalikan Monica

1

Simpan pkgcache.bindan srcpkgcache.bin, Anda dapat dengan aman menghapus yang lain. Jangan menyentuh direktori!


Ok terima kasih. Saya sementara memindahkan *bin.*file ke folder cadangan. Namun, mengapa apt-get mengelola cache di dalam cache? Direktori cache seharusnya bersifat penyimpanan sementara.
ysap

Masalah ini sudah dilaporkan bug. :) Lihat di sini
Frantique

Anda tentu saja dapat menghapus pkgcache.bin dan srcpkgcache.bin, tidak ada yang terjadi. pembaruan apt-get membuat ulang mereka.
Tomas M

0

Anda tentu saja dapat membuat NFS-share (sistem file jaringan) untuk ini. Tinggalkan file-file ini di server dan pasang share hanya ketika Anda ingin memperbarui / menginstal paket. Dalam lingkungan tertanam, instalasi biasanya akan relatif statis.

sshfs adalah pilihan lain yang baik, jauh lebih mudah untuk diatur (pada dasarnya hanya membutuhkan SSH yang standar), tetapi memiliki lebih banyak overhead (lebih lambat).


Ini seharusnya bekerja secara teknis, kecuali Anda tidak memiliki kontrol penuh kapan apt dijalankan. Jika Anda menggunakan sesuatu seperti ini, Anda perlu memastikan bahwa Anda menonaktifkan tugas "otomatis" seperti pekerjaan cron yang menjalankan pembaruan apt-get.
coteyr
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.