Mengapa file ini disembunyikan ketika Anda menjalankan ls?

10

EDIT: Saya benar-benar lupa tentang utas ini. Ternyata saya punya hard disk yang buruk. Kami harus memindahkan server ini untuk kebutuhan lain, jadi saya akhirnya mengganti satu disk yang rusak dan kami kembali berbisnis.

Selama beberapa minggu sekarang saya tidak tahu mengapa saya tidak dapat menghapus file tertentu ini. Sebagai root saya bisa, tetapi skrip shell saya berjalan sebagai pengguna yang berbeda. Jadi saya pergi menjalankan ls -la dan itu tidak ada. Namun, jika saya menyebutnya sebagai parameter, itu muncul! Benar saja, pemiliknya adalah root, maka saya tidak dapat menghapus.

Perhatikan, 6535 hilang ...

[root@server]# ls -la 653*
-rw-rw-r--  1 svn svn  24002 Mar 26 01:00 653
-rw-rw-r--  1 svn svn   7114 Mar 26 01:01 6530
-rw-rw-r--  1 svn svn   8653 Mar 26 01:01 6531
-rw-rw-r--  1 svn svn   6836 Mar 26 01:01 6532
-rw-rw-r--  1 svn svn   3308 Mar 26 01:01 6533
-rw-rw-r--  1 svn svn   3918 Mar 26 01:01 6534
-rw-rw-r--  1 svn svn   3237 Mar 26 01:01 6536
-rw-rw-r--  1 svn svn   3195 Mar 26 01:01 6537
-rw-rw-r--  1 svn svn  27725 Mar 26 01:01 6538
-rw-rw-r--  1 svn svn 263473 Mar 26 01:01 6539

Sekarang muncul jika Anda memanggilnya langsung.

[root@server]# ls -la 6535
-rw-rw-r--  1 root root 3486 Mar 26 01:01 6535

Ini sesuatu yang menarik. Jadi saya menangkap masalah ini karena dalam skrip shell saya, itu akan gagal untuk menghapus karena 6535 dimiliki oleh root. File sebenarnya muncul setelah saya menjalankan "rm -rf." Saya sudah mencoba sebelumnya dan gagal menghapus direktori karena itu memberitahu saya direktori tidak kosong. Saya masuk dan melihat dan cukup yakin, file "6535" akhirnya muncul. Tidak tahu mengapa melakukan ini.

strace mengatakan yang berikut ini 

#strace ls -la 653* 2>&1 | grep ^open

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/tls/librt.so.1", O_RDONLY) = 3
open("/lib64/libacl.so.1", O_RDONLY)    = 3
open("/lib64/libselinux.so.1", O_RDONLY) = 3
open("/lib64/tls/libc.so.6", O_RDONLY)  = 3
open("/lib64/tls/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libattr.so.1", O_RDONLY)   = 3
open("/etc/selinux/config", O_RDONLY)   = 3
open("/proc/mounts", O_RDONLY)          = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/proc/filesystems", O_RDONLY)     = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en_US.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/nsswitch.conf", O_RDONLY)    = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY)           = 3
open("/etc/group", O_RDONLY)            = 3
open("/etc/mtab", O_RDONLY)             = 3
open("/proc/meminfo", O_RDONLY)         = 3
open("/etc/localtime", O_RDONLY)        = 3
linux command-line-interface shell luckytaxi
sumber
2
Jika Anda mengetahui hal ini, silakan kirim pembaruan.
einstiien
Menarik. apa yang dilaporkan dengan ls -ab? Mungkin beberapa karakter non oktal aneh ada di nama file? Saya akan berpikir -saya akan mendaftar tetapi saya tidak yakin.
egorgry
1
Sudahkah Anda menjalankan fsck baru-baru ini? Sangat mungkin ada sesuatu yang rusak pada sistem file.
Zoredache
Saya harus mengujinya lagi besok, berangkat hari itu.
luckytaxi

Jawaban:

7

Itu agak mengkhawatirkan. Saya akan memverifikasi bahwa lsfile Anda tidak dimodifikasi dengan membandingkan dengan file yang dikenal baik. Anda bisa menggunakan alat paket distribusi Anda untuk memverifikasi file pada sistem yang terisolasi.

Warner
sumber
+1: ls -al harus menunjukkan segalanya. Jika tidak ada masalah di suatu tempat.
Satanicpuppy
2
Sangat mungkin yang lstelah dimodifikasi untuk menyembunyikan PID tertentu, mungkin 6535.
MikeyB
Tidak ... tidak ada ...
luckytaxi
6

Terkadang nama file mendapatkan karakter aneh di dalamnya seperti urutan pergerakan kursor. Coba ini untuk memastikan:

ls -lq

Seharusnya menunjukkan tanda tanya alih-alih karakter kontrol (itu mungkin default, tapi mungkin tidak).

Ini sebagian menunjukkan jenis masalah yang mungkin ada:

touch A C
touch B$(tput cuu1)$'\r'
ls -l
ls -lq
ls -l --show-control-chars    # for systems that have that option and default to -q

Saya juga akan mencoba:

type -a ls
alias ls
declare -f ls
md5sum /bin/ls    # compare to a known-good identical system

untuk melihat apakah alias atau fungsi didefinisikan atau untuk melihat apakah biner berada di tempat ganjil atau telah dimodifikasi.

Dijeda sampai pemberitahuan lebih lanjut.
sumber
1
+1 wawasan yang bagus. Penting untuk dicatat bahwa jika lsdimodifikasi, md5sumsistem mungkin berpotensi dimodifikasi juga. Anda perlu lingkungan waras yang dikenal untuk memverifikasi untuk mencapai kesimpulan yang pasti.
Warner
Saya telah menemukan bahwa bahkan jika md5 telah diubah untuk menghasilkan hasil palsu jika Anda melakukan hal-hal seperti 'file md5' Anda masih bisa mendapatkan hasil yang baik (jika program md5 bekerja sama sekali) dengan melakukan sesuatu seperti bzip2 <file | md5 dan membandingkan bahwa untuk perintah yang sama di tempat lain.
chris
3

Anda mungkin ingin fsck volume itu.

Florin Andrei
sumber
13
itu yang dia katakan.
einstiien
2

Saya biasanya melakukan sesuatu seperti ini jika saya percaya 'ls' telah dimodifikasi ...

python -c "import os; print os.listdir('.')"

Tentu saja Python, Perpustakaan C, kernel, atau sistem file juga dapat dimodifikasi, tetapi biasanya itu hanya utilitas shell.

McJeff
sumber
2
Atau, Anda dapat menggunakan ekspansi nama file shell untuk membaca direktori - echo * (dan jika Anda menginginkan semuanya, echo *. *)
chris
*.*hanya akan menunjukkan kepada Anda file yang memiliki karakter diikuti oleh titik diikuti oleh karakter. Ini jelas bukan segalanya pada sistem * nix. Saya tidak yakin gema akan menampilkan semuanya dalam satu perintah, saya bisa melakukannyaecho * && echo .*
einstiien
4
Jika Anda perhatikan dengan seksama, itu adalah * (spasi). *, Bukan *. * Tanda baca tidak cocok untuk sistem komentar ini ... Dan, gema sangat senang untuk memperluas banyak ekspresi yang dipisahkan oleh "$ IFS" sebagai Anda ingin memberinya makan. Boolean && tidak diperlukan, atau bahkan sangat masuk akal, karena && adalah boolean dan dan akan selalu berfungsi karena perintah echo selalu berhasil.
chris
@ Chris: salahku, sangat sulit untuk melihat itu.
einstiien
2

Anda dapat melihat dengan tepat apa yang dilakukan ls dengan menggunakan strace, dan itu bisa memberi tahu Anda mengapa ia tidak menunjukkan nama file itu.

strace ls -la 653* 2>&1 | less

lihat itu dan lihat apa yang terjadi.

strace ls -la 653* 2>&1 | grep ^open

Outputnya akan terlihat seperti ini:

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
open("/lib/libacl.so.1", O_RDONLY)      = 3
open("/lib/libselinux.so.1", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libattr.so.1", O_RDONLY)     = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libsepol.so.1", O_RDONLY)    = 3
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3

dan jika Anda melihat sesuatu seperti

open("/var/tmp/.../H@ckl1st", O_RDONLY) = 3

berhati-hatilah, kamu telah memiliki ...

Ini bukan tes konklusif, tetapi merupakan indikator yang baik ...

(jika Anda menggunakan solaris atau OS lain, Anda mungkin perlu menggunakan rangka, atau utilitas serupa lainnya alih-alih strace)

(jika Anda menggunakan shell turunan csh / tcsh, Anda mungkin membutuhkan pernyataan redirection yang berbeda)

chris
sumber
Saya suka ini. The straceutilitas benar-benar adalah pisau tentara swiss. Anda bisa langsung ke level panggilan sistem dan melewati tumpukan kerumitan yang sewenang-wenang. Ini adalah salah satu hal pertama yang dilakukan admin sistem. layak sepeser pun harus membuang pada mesin yang baru diinstal.
McJeff
Ya - dua alat paling berharga untuk administrator sistem adalah truss / strace dan tcpdump. Dengan ini, Anda selalu dapat melihat di bawah selimut untuk melihat apakah terjadi ketika ada sesuatu yang tidak sesuai dengan yang Anda harapkan.
chris
2

Pembaruan cepat, kami harus mengganti server karena alasan lain. Itu adalah sistem file. Semuanya baik-baik saja !!! Terima kasih semuanya.

luckytaxi
sumber
Maksud Anda filesystem itu kacau dan ini hanya gejala aneh?
chris
ya itu saja.
luckytaxi
Anda mungkin bisa terjebak dalam pengeditan untuk mengatakan ada solusi dalam daftar di bawah ini, karena jawaban itu telah terkubur di bawah jawaban yang tervotifikasi (dan berguna untuk pemecahan masalah) lainnya.
Bart Silverstrim
0

Teori retas memang menarik, tapi saya punya teori alternatif. Semantik penghapusan file Unix akan menjaga file di sekitar sampai semua proses telah ditutup menangani file yang mengarah padanya. Mungkin seseorang telah menghentikan checkout / commit SVN, atau utas server terputus. Jika memulai kembali proses SVN (atau Apache) menyelesaikan masalah Anda, ini adalah tempat saya menyalahkan.

Mungkin Anda dapat mengidentifikasi proses masih menggunakan file ini dengan lsof | grep 6535?

jldugger
sumber
ya dia tidak menunjukkan apa-apa. Yang menarik adalah, 6535 juga "hilang" di sumbernya. Script saya melakukan hotcopy dari repo asli ke direktori lain. Saat itulah saya mengalami masalah dengan tidak dapat menghapus file tertentu ini karena beberapa alasan.
luckytaxi
File yang dihapus tetapi terbuka tidak akan mencegah Anda menghapus direktori yang berisi karena begitu entri direktori itu dihapus, entri direktori tidak akan ada sehingga direktori akan kosong. Anda tidak akan mendapatkan ruang kembali dari file sampai proses yang dibuka dibuka, tetapi direktori yang memiliki file itu sekarang dapat dihapus.
chris
Teori alternatif Anda menarik. Penghapusan, jika berhasil, akan langsung menghapus tautan keras. Inode kemungkinan masih berisi data dan beberapa file menangani mungkin di-cache di memori, tapi saya tidak percaya skenario ini bisa menjelaskan perilaku yang dijelaskan. Atau, apa kata chris, heh.
Warner