Bisakah bash tidak sinkron dengan sistem file?

Saya mungkin tidak mengutarakan pertanyaan saya dengan benar, tetapi saya akan melakukan yang terbaik untuk menjelaskan gejala yang saya alami. Pertama, untuk konteks, saya menjalankan server Ubuntu (tanpa GUI), versi 12.04.3 LTS (sesuai dengan utilitas lsb_release). Saya biasanya melakukan semua pekerjaan saya di tmux, saya terhubung ke server melalui Putty, dan saya menggunakan vim untuk semua pengeditan teks saya.

Sekarang untuk gejalanya. Karena saya menggunakan tmux, saya biasanya memiliki beberapa jendela terbuka setiap saat. Salah satunya merumahkan server simpul yang telah saya mainkan, dan tinggal di subdirektori dari rumah akun pengguna saya (khususnya, ~/battleship). Server berinteraksi dengan halaman web yang saya hosting dari server menggunakan nginx, dan semua kode situs tinggal /usr/share/nginx/www/bs(saya juga membuka jendela terpisah untuk mengedit sumber klien). Apa yang terjadi adalah bahwa setelah beberapa jam membiarkan jendela server diam dan tidak tersentuh, sepertinya tidak sinkron. Saya dapat menjalankan lsdan melihat file, dan saya dapat membukanya untuk diedit ( vim server.js). Ketika saya melakukan itu, bagaimanapun, terlepas dari apakah saya membuat perubahan dan menyimpan atau hanya berhenti secara instan, ketika saya menjalankanlslagi saya melihat file .server.js.swp, dan tidak ada perubahan saya (jika saya membuat) tetap ada. Jika saya keluar dari direktori itu dan kemudian kembali, itu memperbaiki sendiri - saya dapat membuka file dan mengeditnya dengan sukses, tanpa meninggalkan .swp ketika saya menutupnya. Saya menyebutkan sumber setengah dari sumber klien karena saya perhatikan bahwa ini tidak terjadi di folder / www (mungkin karena itu di luar direktori home akun pengguna saya).

Setelah tembok teks itu, pertanyaan saya adalah ini: Adakah yang tahu mengapa ini terjadi, dan bagaimana cara mencegahnya? Saya hanya bisa membayangkan ada beberapa cara, mengingat ini bukan satu-satunya server Linux yang saya hubungkan melalui Putty dan menggunakan tmux / vim, namun itu satu-satunya di mana perilaku aneh ini terjadi. Bantuan apa pun akan dihargai.

Catatan: Saya menandai ini dengan bash, tmux, dan dempul karena saya berasumsi salah satu dari mereka yang harus disalahkan tetapi saya benar-benar tidak tahu.

Pembaruan: Ini adalah output cat /proc/mountseperti yang diminta oleh Gilles (walaupun dengan nama pengguna saya dan nilai-nilai ecryptfs_fnek_sigdan ecryptfs_sigdisensor, karena sementara saya tidak benar-benar tahu apa dua hal itu, mereka tampaknya terkait enkripsi, dan lebih baik aman daripada menyesal).

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=2008532k,nr_inodes=502133,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=807840k,mode=755 0 0
/dev/disk/by-uuid/2da27263-f079-47ba-90ad-66e4c3a53810 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/home/[username]/.Private /home/[username] ecryptfs rw,relatime,ecryptfs_fnek_sig=[censored],ecryptfs_sig=[censored],ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

Pembaruan 2: Inilah output dari uname -a:

Linux [server-name] 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Pembaruan 3: Saya menyelesaikan lulus tes. Ini adalah hasil dari tes tersebut . Tampaknya telah selesai tanpa kesalahan, jadi saya tidak yakin apakah itu akan membantu sesuatu. Anda juga dapat melihat beberapa perincian peranti keras untuk berjaga-jaga.

bash putty tmux

— Alex
sumber

Tidak, bash tidak dapat "tidak sinkron dengan sistem file", dan toh bukan itu yang terjadi. Ini lebih seperti filesystem yang keluar dari sinkronisasi dengan filesystem. Ini benar-benar masalah, dan yang aneh. Sistem file apa yang Anda gunakan (memposting output cat /proc/mounts)? Ini mungkin server yang tervirtualisasi, virtualisasi macam apa yang digunakannya?

— Gilles 'SO- stop being evil'

@Gilles Saya memperbarui pertanyaan untuk memasukkan output cat /proc/mountsuntuk Anda. Mudah-mudahan itu akan berarti bagi Anda - saya masih cukup baru untuk Linux, jadi ada banyak belajar dengan melakukan, dan saya belum melihat-lihat dengan sistem file sama sekali (di luar menggunakannya).

— Alex

Jadi masalah terjadi pada sistem file ecryptfs. Ini terlihat seperti bug di ecryptfs, atau di bagian lain dari kernel, atau di perangkat lunak virtualisasi jika berlaku, atau kesalahan perangkat keras. Apakah ini berjalan di perangkat keras Anda sendiri di dalam kotak atau di rak, atau apakah ini server virtual dengan beberapa penyedia hosting? Apa output dari uname -a? Jika itu adalah perangkat keras Anda, colokkan konsol dan lakukan tes memori pada boot berikutnya. Jika dihosting, hubungi penyedia hosting Anda dan jelaskan gejala ini.

— Gilles 'SANGAT berhenti menjadi jahat'

Jika Anda menjalankan, sudo syncapakah file diperbarui?

— Braiam

Cobalah perintah sinkronisasi. Df cmd juga berguna untuk menunjukkan di mana dir tinggal. Suka / proc / mount tetapi output lebih mudah dibaca. Lakukan df -h /www ~/battleship /usr/share/nginx/www/bs. Apakah masalah dengan mounts enkripsi? Mungkin pemrosesan sw tambahan diperlukan untuk menulis ke disk itu sehingga ada caching atau ada sesuatu yang terjadi dengan itu?

— gaoithe

Jawaban:

Satu-satunya pengalaman yang pernah saya lihat dengan sesuatu seperti ini adalah ketika direktori sedang dihapus dan yang baru dibuat. AIX dan Solaris memiliki masalah ini bertahun-tahun yang lalu. Jika Anda memiliki sesi shell terbuka di direktori yang dihapus Anda bisa mendapatkan kembali hasil yang tidak terduga yang terlihat seperti sistem file yang keluar dari sinkronisasi.

bash1: mkdir test1
bash2: cd test1
bash1: touch test1/testfile
bash1: ls test1
testfile
bash2: ls
testfile
bash1: rm -rf test1
bash2: ls
???(unknown results)???

Sistem file terenkripsi juga terdengar seperti sesuatu untuk ditinjau. Sudahkah Anda mencoba dalam sistem file yang tidak dienkripsi?

Maaf saya belum bisa mengirim komentar. Tidak cukup poin.

— Michael McGarrah
sumber

Ini relevan dengan pertanyaan, dengan bash shell dibiarkan dengan direktori default yang tidak ada, dan di mana tidak mungkin untuk membuat file.

— ubfan1

Saya dapat mencoba eksperimen kecil ini, tetapi saya cukup yakin pada titik ini bahwa ini adalah masalah ecryptfs. Direktori yang dimaksud pasti masih ada; Saya dapat bekerja secara normal setelah sederhana cd .ketika saya kembali ke sesi setelah beberapa saat. Pada titik ini saya jujur hanya mempertimbangkan untuk mencadangkan semuanya, menghapus server, dan menginstal ulang tanpa sistem file terenkripsi. Saya tidak menyimpan apa pun yang penting, jadi saya tidak terlalu khawatir mengenkripsi file saya.

— Alex

Pengelola / penulis eCryptfs di Ubuntu sangat responsif terhadap laporan bug. Jika Anda tidak dapat menemukan solusi, mungkin ada baiknya menanyakannya atau mengajukan laporan bug.

— blujay

Anda bisa mencoba menjalankan perintah sinkronisasi di antara perintah bash Anda.

sync - flush file system buffers

Saya tidak pernah menemukan kebutuhan untuk itu sendiri tetapi telah mengetahui setidaknya satu orang yang mengetiknya praktis seperti setiap perintah kedua! Pasti pernah terbakar parah di masa lalu dengan disk yang lambat.

Internet tampaknya ringan pada diskusi tentang penggunaan syncperintah. Berikut ini tautan ke entri manual yang sangat singkat untuk sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncmenjamin bahwa data ditulis dari memori ke perangkat disk. Data masih bisa di memori cache perangkat disk dan tidak ditulis ke disk jika perangkat disk itu sendiri lambat atau memiliki masalah.

Anda menjalankan server ubuntu. . . apakah itu mesin di desktop Anda? Atau apakah itu di awan? Atau . . . sesuatu yang lain? Lihat di sini: /server/534627/what-does-the-sync-command-do sinkronisasi lambat dari memori ke disk yang terkait dengan masalah hard disk ATAU mungkin dengan instance Amazon AWS yang lebih kecil.

— gaoithe
sumber

Saya tidak yakin apakah syncakan ada gunanya; Saya telah menemukan bahwa hanya dengan melakukan cd .mengurangi masalah itu. Saya membuat alias refuntuk itu (saya tahu, menyelamatkan satu karakter agak konyol) yang biasa saya gunakan setiap kali saya kembali ke sesi lama sekarang. Adapun apa servernya, itu adalah menara desktop lama saya (saya membuat yang baru tahun lalu) yang sekarang tinggal di sudut ruang tamu saya yang menjalankan distro Ubuntu, jadi saya memiliki akses penuh ke perangkat keras dan kekuasaan atas apa yang sedang berjalan di atasnya.

— Alex

FWIW masalah ditampilkan oleh perintah ls, bukan oleh bash.

Fakta bahwa Anda melihat file itu berarti masih ada di sana. Tidak ada yang tidak sinkron dengan hal lain dan tidak ada jumlah sinkronisasi yang berjalan akan menghentikan Anda dari menggunakan satu-satunya salinan cache dari data sistem file yang relevan. sinkronisasi hanya akan menyebabkan data komit ke penyimpanan permanen, tidak mengubah pandangan Anda tentang itu.

Apakah Anda menggunakan sesi VIM? Saya tidak tahu sesi VIM, tidak pernah menggunakannya sendiri, tapi saya membayangkan tmux mungkin menyebabkan manajer sesi VI tidak menyadari file ditutup dan untuk menjaga perubahan Anda dilacak.

— Johan
sumber