Ls çalıştırdığınızda bu dosya neden gizli?

EDIT: Bu konuyu tamamen unuttum. Görünüşe göre kötü bir sabit diskim vardı. Bu sunucuyu diğer ihtiyaçlar için yeniden dağıtmak zorunda kaldık, bu yüzden sonunda tek bir kötü diski değiştirmeye başladım ve işimize geri döndük.

Birkaç hafta boyunca bu dosyayı neden silemediğimi anlayamadım. Kök olarak yapabilirim, ancak kabuk betiğim farklı bir kullanıcı olarak çalışıyor. Bu yüzden ls -la koşuyorum ve orada değil. Ancak, parametre olarak çağırırsam, görünür! Tabii ki, sahibi kök, bu yüzden silmek mümkün değil.

Dikkat, 6535 eksik ...

[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

Şimdi doğrudan ararsanız görünür.

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

İşte ilginç bir şey. Bu sorunu yakaladım, çünkü kabuk komut dosyamda, 6535 kök tarafından sahip olduğu için silinemedi. Dosya "rm -rf" komutunu çalıştırdıktan sonra görünüyor. Daha önce denedim ve dizin boş olmadığını söyledi çünkü dizini kaldırmak için başarısız oldu. İçeri girdim ve baktım ve yeterince "6535" dosyası nihayet ortaya çıktı. Bunu neden yaptığını bilmiyorum.

strace diyor ki

#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

Bu biraz endişe verici. lsBilinen iyi bir dosyayla karşılaştırarak dosyanızın değiştirilmediğini doğrularım . Yalıtılmış bir sistemde dosyayı doğrulamak için dağıtımınızın paket araçlarını kullanabilirsiniz.

Bazen dosya adları imleç hareket dizileri gibi garip karakterler alır. Emin olmak için şunu deneyin:

ls -lq

Kontrol karakterleri yerine soru işaretlerini göstermelidir (muhtemelen varsayılandır, ancak olmayabilir).

Bu kısmen mevcut olabilecek problem türünü gösterir:

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

Ben de denemek istiyorum:

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

bir takma adın veya işlevin tanımlanmış olup olmadığını veya bir ikiliğin tek bir yerde mi yoksa değiştirilmiş mi olduğunu görmek için.

Bu birimi izlemek isteyebilirsiniz.

'Ls' değiştirildiğine inanırsam genellikle böyle bir şey yaparım ...

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

Elbette Python, C Kütüphanesi, çekirdek veya dosya sistemi de değiştirilebilir, ancak genellikle sadece kabuk araçlarıdır.

Strace kullanarak tam olarak ne yaptığını inceleyebilirsiniz ve bu neden bu dosya adını göstermekten kaçındığını söyleyebilir.

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

şuna bakın ve neler olduğunu görün.

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

Çıktı şöyle görünecektir:

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

ve eğer böyle bir şey görürsen

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

Dikkatli ol, sen 0wn ...

Bu kesin bir test değil, ama iyi bir göstergedir ...

(solaris veya diğer işletim sistemlerini kullanıyorsanız, kafes yerine kafes veya başka bir benzer yardımcı program kullanmanız gerekebilir)

(csh / tcsh türetilmiş bir kabuk kullanıyorsanız, muhtemelen farklı yönlendirme ifadelerine ihtiyacınız olacaktır)

Hızlı güncelleme, sunucuyu başka nedenlerle değiştirmek zorunda kaldık. Dosya sistemiydi. Şimdi her şey yolunda !!! Herkese teşekkürler.

Hack teorisi ilginç, ama alternatif bir teorim var. Unix dosyası silme semantiği, tüm işlemler ona işaret eden açık dosya tanıtıcılarını kapanıncaya kadar dosyayı saklar. Belki birisi SVN ödeme / işlemini duraklattı veya bir sunucu iş parçacığı askıya alındı. SVN işlemini (veya Apache) yeniden başlatmak sorununuzu çözerse, işte suçu bulacağım yer.

Belki de hala bu dosyayı kullanarak süreci tanımlayabilirsiniz lsof | grep 6535?