Saya menggunakan Stretch Debian. Partisi root saya sudah terpasang read-only
. Hanya ketika saya menginstal atau memutakhirkan paket, di- /
remount ke read-write
(dengan menggunakan apt hook), dan kemudian di-remount kembali ke ro
.
Terkadang setelah peningkatan paket, saya tidak dapat melakukan remount /
kembali menjadi read-only:
mount -o remount,ro /
mount: / is busy
Pada versi Debian yang lebih lama (Wheezy), saya dapat membuat daftar file yang terbuka yang tidak terhubung dengan lsof
:
lsof +L1
atau, lebih khusus, file yang mencegah agar tidak di /
-remount kembali ke ro:
{ lsof +L1 ; lsof|sed -n '/SYSV/d; /DEL|(path /p;' ; } | grep -Ev '/(dev|home|tmp|var)'
Namun, pada Debian Stretch, lsof +L1
tidak mencantumkan file apa pun.
Saya tidak melihat perubahan apa pun +|-L
di man lsof
dalamnya yang akan menjelaskan mengapa itu berhenti berfungsi.
Mengapa lsof + L1 tidak lagi daftar membuka file yang telah dibatalkan tautannya?
Bagaimana saya bisa mendaftar file-file yang mencegah / dari yang remount menjadi hanya-baca?
MEMPERBARUI
Saya telah menghentikan semua proses yang dapat dihentikan, dan hanya memiliki init
dan getty
masih berjalan, tetapi saya masih tidak bisa melakukan remount /
ke ro
.
w
atauu
diFD
kolomlsof
output, atauF
di outputfuser -vm /
, misalnya. Saya tidak bisa memberi Anda daftar lengkap. Anda mungkin juga ingin menginstal paket needrestart .root
?fuser -m /
tahu apa yang menggunakan root?Jawaban:
Bagaimana saya bisa mendaftar file-file yang mencegah / dari yang remount menjadi hanya-baca?
A)
fuser
dapat ditemukan dalampsmisc
paket; ini adalah kasus penggunaan di mana saya menemukanfuser
bersinar & lebih berguna daripadalsof
.# fuser -v -m / 2>&1 | grep '[Ff]r.e'
Itu akan menunjukkan semua proses yang memiliki file terbuka pada / untuk membaca (f) dan menulis (F). File yang akan mencegah / tidak di-remount ke read-only adalah file yang dibuka untuk ditulis (F).
Bunuh proses yang dapat dijalankan yang dijalankan dengan file direktori root terbuka untuk ditulis ., Yaitu
# for fupid in $(fuser -v -m / 2>&1 | grep Fr.e | awk '{print $2}'); do kill $fupid; done
Itu di atas
systemd
komentar dengan peringatan. Jikasystemd
sudahinit
makafuser
akan melihatnya dan ada pertimbangan lain. Dengansystemd
berlari, ia dapat memulai kembali proses di belakang Anda, bahkan jika mereka baru saja diidentifikasi dan dibunuhfuser
.systemd
jauh lebih maju daripada tradisionalsysvinit
.B) UPDATE dalam deskripsi menyatakan sistem hanya memiliki ...
init
dangetty
masih berjalan ...Saya melihat komentar yang mengatakan sistem tidak menggunakan
systemd
, itu menggunakaninit
. Pada peregangan,systemd
adalahinit
. Komentar tidak secara eksplisit mengatakansysvinit
, jadi saya mengasumsikan sistem yang dimaksud mungkin menggunakan peregangan defaultsystemd
untukinit
. Atau orang lain yang tersandung pada postingan ini, yang menggunakan stretchsystemd
, merasa bagian ini bermanfaat.Per Wiki Debian ,
Dengan
systemd
menjalankan, ada beberapa langkah tambahan yang harus diambil untuk membebaskan / sehingga dapat dipasang kembali tanpa masalah.Kemungkinan
system.slice
memegang file terbuka untuksystemd-journald.service
atausystemd-udevd.service
(keduanya memiliki dependensi soket). Atau, jikaNetworkManager
dijalankan, ia dapat muncul kembalidhclient
yang menulis leases ke / var / ... (& / var / tidak selalu merupakan perangkatnya sendiri), dll.fuser
Mungkin menemukan & Anda membunuhdhclient
tetapiNetworkManager
memulainya kembali.Moralnya adalah banyak hal bersifat otomatis yang bisa 'diinginkan' / (dan terlebih lagi dengan
systemd
).Yang pasti, jika layak,
systemd
setara dengan level run 1 dicocokkan denganrescue.target
(danrunlevel1.target
merupakan tautan simbolis kerescue.target
).1) Mulailah dengan mengisolasi sistem ke
rescue.target
# systemctl isolate rescue.target
Ini akan meminta Anda untuk memasukkan kata sandi root; ikuti petunjuk di layar.
2) Di shell penyelamatan, cari tahu apa yang diinginkan /.
# systemctl show -p Wants /
Biasanya, ini
system.slice
; hentikan semua yang Ingin. misalnya# systemctl stop system.slice
3) Pada titik ini, remount tidak boleh dilaporkan
mount: / is busy
danmount -o remount,ro /
seharusnya berfungsi. Jika tidak, periksa lagi denganfuser
.4) FWIW; Saya juga pernah melihat saat
umount
gagal ketika / jika perangkat lain dipasang pada sub-direktori mount lain, yaitu nested mounts. Misalnya,umount /
akan gagal jika / var / atau / boot / ada di perangkat lain (dan terpasang). Padahalmount -o remount,ro /
harus tetap bekerja dalam hal ini.lsblk
dapat membantu untuk memvisualisasikan mount bersarang.Mengapa lsof + L1 tidak lagi daftar membuka file yang telah dibatalkan tautannya?
Karena tidak tersedia (soket atau sebagian besar FIFO & pipa), mereka tidak lagi membuka file (proses induk menutup deskriptor file), atau mereka (masih) memiliki jumlah tautan lebih dari 1.
man lsof (8) detail ...
sumber
Apakah Anda sudah
/proc
memasang?Benar-benar menjadi seseorang yang berhati-hati
/
untuk me - mount read-only sebagian besar waktu, saya bisa membayangkan Anda mungkin juga memilih untuk tidak me-mount procfs. Tetapi procfs diperlukan untuklsof
menemukan file yang terbuka.File yang dipegang terbuka oleh proses diekspos oleh kernel melalui tautan simbolik di procfs. Direktori
/proc/<pid>/fd
berisi symlink untuk setiap file yang dibuka. Nama symlink adalah nomor deskriptor file, dan path yang dirujuk oleh symlink adalah path file.Symlink yang menggantung masih tetap ada
/proc
untuk file terbuka yang sudah dihapus. Dan jalur file yang direferensikan akan diganti untuk diakhiri dengan "(dihapus)".Apa yang
lsof +L1
dilakukan pada dasarnya tidak berbeda dengan quick-liner seperti:Jadi, Anda dapat menggunakan one-liner serupa untuk mendaftar semua file yang terbuka yang dapat mencegah sistem file root di-remount (asalkan berfungsi
/proc
).Namun jika Anda telah / sudah melakukan
/proc
mount, satu-satunya penyebab lain yang dapat saya pikirkan adalah bug ... Ngomong-ngomong, FYI, pada sistem Debian Stretch saya saat ini.lsof +L1
bekerja seperti yang diharapkan.sumber
/proc
mount. Saya tidak mengikuti alasan Anda mengapa saya tidak melakukannya. Bagaimanapun, tidakstat -c%N /proc/[0-9]*/fd/* | grep deleted
menunjukkan apa-apa padaku.Aku bisa mereproduksi masalah ini hanya sekali, dan diselesaikan dengan hanya menggunakan
mount
dengan n pilihan.Mengutip man mount :
The
mount
program itu sendiri membuka file (s) untuk menulis dalam sistem file root terdengar seperti penjelasan yang masuk akal bagi saya. Secara khususmount
menulis/etc/mtab
setelah semua dan/etc
sering merupakan bagian dari sistem file root. Namun saya tidak dapat mereproduksi lagi di mesin yang sama setelah saya melakukannya sekali ...Bisakah ini menyelesaikan masalah Anda?
sumber
-n
dengan mount tidak ada bedanya.Tanpa visibilitas ke sistem Anda, sangat sulit untuk memberi tahu Anda apa masalahnya. Komentar dan jawaban sebelumnya adalah awal yang baik.
Yang mengatakan, saya akan kembali semua melalui wiki debian yang menggambarkan prereq untuk pemasangan / baca saja.
Tautan ke dokumentasi ada di sini: https://wiki.debian.org/ReadonlyRoot
Yang besar saya akan memandu Anda ke sini:
1 - ada lokasi tertentu di bawah / yang harus dibaca tulis. Berdasarkan dokumentasi terlihat seperti ini:
perangkat blok Anda mungkin akan berbeda, tergantung pada konfigurasi tumpukan penyimpanan Anda (partisi, lvm partionless, dll.) tetapi gagasan utamanya adalah bahwa Anda memerlukan 4 titik pemasangan agar sistem file yang dipasang berikutnya untuk memiliki opsi pemasangan RW.
2 - ada sejumlah file khusus di / etc yang Anda perlukan untuk membuat tautan simbolis untuk atau menerapkan beberapa perubahan lainnya (secara khusus dirinci dalam artikel tertaut.). Ini mungkin atau mungkin tidak berlaku berdasarkan aplikasi apa yang dijalankan server linux Anda. beberapa file bahkan mungkin tidak ada di mesin Anda, tetapi saya memasukkan semuanya dalam dokumen. Perlu diingat, saya sangat menyarankan untuk melakukan perubahan ini BAHKAN JIKA Anda telah membunuh pid dari proses. Berikut ini jalur langsung dari wiki debian:
Setelah Anda memeriksa semua hal di atas dan mengonfirmasi bahwa mereka sesuai dengan spesifikasi di wiki, hal berikutnya yang perlu diperiksa adalah /etc/apt/apt.conf
berdasarkan kesalahan Anda, hal terakhir yang dapat Anda periksa berdasarkan dokumentasi berasal dari di bawah ini:
"Setelah pemutakhiran paket Anda mungkin dihadapkan dengan masalah yang me-mount menolak untuk me-remount sistem file yang hanya memberitahu Anda" / sedang sibuk. "Ini disebabkan oleh file yang dihapus mereka masih digunakan oleh suatu proses. file menggunakan tool checkrestart (1) dari paket debian-goodies atau gunakan perintah berikut. Seringkali ini adalah daemon yang menggunakan pustaka yang ditingkatkan. Anda harus me-restart mereka untuk membuat file dirilis. "
perintah yang disediakan di doc .:
Tanpa mengetahui konfigurasi sistem file, partioning, dan konfigurasi perangkat penyimpanan Anda, sulit memberi Anda banyak hal untuk diikuti. Saya akan mulai dengan kembali dan memeriksa kembali prereq Anda di dokumentasi (dan diuraikan di atas).
sumber