Tidak dapat melakukan remount / kembali ke read-only setelah peningkatan paket

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 +L1tidak mencantumkan file apa pun.

Saya tidak melihat perubahan apa pun +|-Ldi man lsofdalamnya 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 initdan gettymasih berjalan, tetapi saya masih tidak bisa melakukan remount /ke ro.

Bagaimana saya bisa mendaftar file-file yang mencegah / dari yang remount menjadi hanya-baca?

A) fuserdapat ditemukan dalam psmiscpaket; ini adalah kasus penggunaan di mana saya menemukan fuserbersinar & lebih berguna daripada lsof.

# 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 systemdkomentar dengan peringatan. Jika systemdsudah initmaka fuserakan melihatnya dan ada pertimbangan lain. Dengan systemdberlari, ia dapat memulai kembali proses di belakang Anda, bahkan jika mereka baru saja diidentifikasi dan dibunuh fuser. systemdjauh lebih maju daripada tradisional sysvinit.

B) UPDATE dalam deskripsi menyatakan sistem hanya memiliki ... initdan gettymasih berjalan ...

Saya melihat komentar yang mengatakan sistem tidak menggunakan systemd, itu menggunakan init. Pada peregangan, systemd adalah init . Komentar tidak secara eksplisit mengatakan sysvinit, jadi saya mengasumsikan sistem yang dimaksud mungkin menggunakan peregangan default systemduntuk init. Atau orang lain yang tersandung pada postingan ini, yang menggunakan stretch systemd, merasa bagian ini bermanfaat.

Per Wiki Debian ,

Proses inisialisasi sistem ditangani oleh daemon init. Dalam rilis pemerasan dan sebelumnya, daemon itu disediakan oleh paket sysvinit, dan tidak ada alternatif yang didukung. Dalam wheezy , daemon init default masihsysvinit , tetapi "pratinjau teknologi" dari systemd tersedia. Dalam jessie dan stretch , sistem init default adalahsystemd , tetapi beralih ke sysvinit didukung.

Sejak jessie, hanya systemd yang didukung sepenuhnya; sysvinit sebagian besar didukung, tetapi paket Debian tidak diharuskan untuk menyediakan skrip start sysvinit. runit juga dikemas, tetapi belum menerima tingkat pengujian dan dukungan yang sama dengan yang lain, dan saat ini tidak didukung sebagai PID 1.

Dengan systemdmenjalankan, ada beberapa langkah tambahan yang harus diambil untuk membebaskan / sehingga dapat dipasang kembali tanpa masalah.

Kemungkinan system.slicememegang file terbuka untuk systemd-journald.serviceatau systemd-udevd.service(keduanya memiliki dependensi soket). Atau, jika NetworkManagerdijalankan, ia dapat muncul kembali dhclientyang menulis leases ke / var / ... (& / var / tidak selalu merupakan perangkatnya sendiri), dll. fuserMungkin menemukan & Anda membunuh dhclienttetapi NetworkManagermemulainya kembali.

Moralnya adalah banyak hal bersifat otomatis yang bisa 'diinginkan' / (dan terlebih lagi dengan systemd).

Yang pasti, jika layak, systemdsetara dengan level run 1 dicocokkan dengan rescue.target(dan runlevel1.targetmerupakan tautan simbolis ke rescue.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 busydan mount -o remount,ro / seharusnya berfungsi. Jika tidak, periksa lagi dengan fuser.

4) FWIW; Saya juga pernah melihat saat umountgagal 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). Padahal mount -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 ...

+ | -L [l]

Opsi ini memungkinkan ('+') atau menonaktifkan ('-') daftar jumlah tautan file, jika tersedia - misalnya, mereka tidak tersedia untuk soket, atau sebagian besar FIFO dan pipa.

Ketika + L ditentukan tanpa nomor berikut, semua jumlah tautan akan dicantumkan. Ketika -L ditentukan (default), tidak ada jumlah tautan akan terdaftar.

Ketika + L diikuti oleh angka, hanya file yang memiliki jumlah tautan yang kurang dari jumlah itu yang akan terdaftar . (Tidak ada angka yang dapat mengikuti -L.) Spesifikasi formulir '' + L1 '' akan memilih file yang terbuka yang telah dibatalkan tautannya. Spesifikasi formulir +aL1 <file_system>akan memilih file terbuka yang tidak ditautkan pada sistem file yang ditentukan.

Apakah Anda sudah /procmemasang?

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 untuk lsofmenemukan file yang terbuka.

File yang dipegang terbuka oleh proses diekspos oleh kernel melalui tautan simbolik di procfs. Direktori /proc/<pid>/fdberisi 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 /procuntuk file terbuka yang sudah dihapus. Dan jalur file yang direferensikan akan diganti untuk diakhiri dengan "(dihapus)".

Apa yang lsof +L1dilakukan pada dasarnya tidak berbeda dengan quick-liner seperti:

stat -c%N /proc/[0-9]*/fd/* | grep deleted

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 /procmount, satu-satunya penyebab lain yang dapat saya pikirkan adalah bug ... Ngomong-ngomong, FYI, pada sistem Debian Stretch saya saat ini. lsof +L1bekerja seperti yang diharapkan.

bash# lsb_release -d
Description:    Debian GNU/Linux 9.5 (stretch)

bash# uname -a
Linux bwp-249-8 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux

bash# lsof -v
lsof version information:
    revision: 4.89
    [...]

Aku bisa mereproduksi masalah ini hanya sekali, dan diselesaikan dengan hanya menggunakan mountdengan n pilihan.

Mengutip man mount :

-n, --no-mtab
      Mount without writing in /etc/mtab.  This is necessary for example when /etc is on a read-only filesystem.

The mountprogram itu sendiri membuka file (s) untuk menulis dalam sistem file root terdengar seperti penjelasan yang masuk akal bagi saya. Secara khusus mountmenulis /etc/mtabsetelah semua dan /etcsering 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?

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:

• adjtime
• init.d / alsa-utils
• / etc / kurir / shared / index
• setiap cangkir menyatakan file, classes.conf, cupsd.conf, printers.conf subscription.conf
• /etc/lvm/lvm.conf
• mtab (yang sepertinya Anda coba atasi dengan memberikan mount -n flag)
• jaringan / run (digunakan oleh ifup dan ifdown, dalam pemerasan. mungkin tidak berlaku untuk peregangan, ymmv)
• nologin
• resolv.conf
• baik file passwd dan shadow
• samba / dhcp.conf
• mengisap
• udev

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

DPkg {
// Auto re-mounting of a readonly /
Pre-Invoke { "mount -o remount,rw /"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro / || true"; };
}; 

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

{lsof +L1; lsof|sed -n '/SYSV/d; /DEL\|(path /p;'} |grep -Ev '/(dev|home|tmp|var)'

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