편집 : 나는이 스레드에 대해 완전히 잊어 버렸습니다. 하드 디스크에 문제가있는 것 같습니다. 우리는 다른 요구를 위해이 서버를 재배치해야했기 때문에 마침내 하나의 불량 디스크를 교체 할 수있게되었습니다.
몇 주 동안이 특정 파일을 삭제할 수없는 이유를 알 수 없었습니다. 루트로 할 수는 있지만 쉘 스크립트는 다른 사용자로 실행됩니다. 그래서 ls -la를 실행하면 거기에 없습니다. 그러나 매개 변수로 호출하면 나타납니다! 물론 소유자는 루트이므로 삭제할 수 없습니다.
6535가 누락되었습니다 …
[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
이제 직접 호출하면 나타납니다.
[root@server]# ls -la 6535
-rw-rw-r-- 1 root root 3486 Mar 26 01:01 6535
흥미로운 점이 있습니다. 그래서 쉘 스크립트에서 6535가 루트 소유이기 때문에 삭제하지 못하기 때문에이 문제가 발생했습니다. “rm -rf”를 실행하면 실제로 파일이 표시됩니다. 이전에 시도했지만 디렉토리가 비어 있지 않다고 말했기 때문에 디렉토리를 제거하지 못했습니다. 나는 들어가서 충분히 보았고 파일 “6535”가 마침내 나타납니다. 왜이 일을하는지 모르겠습니다.
strace는 다음과 같이 말합니다.
#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
답변
조금 걱정 스럽다. ls알려진 양호한 파일과 비교 하여 파일이 수정되지 않았 음을 확인했습니다 . 배포판의 패키지 도구를 사용하여 격리 된 시스템에서 파일을 확인할 수 있습니다.
답변
때때로 파일 이름은 커서 이동 시퀀스와 같이 이상한 문자를 얻습니다. 다음을 확인하십시오.
ls -lq
제어 문자 대신 물음표를 표시해야합니다 (기본값 일 수도 있지만 아닐 수도 있음).
이것은 부분적으로 존재할 수있는 문제의 유형을 보여줍니다.
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
나는 또한 시도 할 것이다 :
type -a ls
alias ls
declare -f ls
md5sum /bin/ls # compare to a known-good identical system
별명 또는 함수가 정의되어 있는지 또는 2 진이 이상한 곳에 있는지 또는 수정되었는지 확인하십시오.
답변
해당 볼륨을 fsck하고 싶을 수도 있습니다.
답변
‘ls’가 수정되었다고 생각되면 일반적으로 이와 같은 작업을 수행합니다 …
python -c "import os; print os.listdir('.')"
물론 Python, C 라이브러리, 커널 또는 파일 시스템 도 수정할 수 있지만 일반적으로 쉘 유틸리티 일뿐입니다.
답변
strace를 사용하여 ls가 수행하는 작업을 정확하게 조사 할 수 있으며 해당 파일 이름을 표시하지 않는 이유를 알 수 있습니다.
strace ls -la 653* 2>&1 | less
그것을 통해 그것을보고 무슨 일이 일어나고 있는지보십시오.
strace ls -la 653* 2>&1 | grep ^open
결과는 다음과 같습니다.
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
그리고 당신이 같은 것을 본다면
open("/var/tmp/.../H@ckl1st", O_RDONLY) = 3
조심하십시오, 당신은 0 소유되었습니다 …
이것은 결정적인 테스트는 아니지만 좋은 지표입니다 …
(Solaris 또는 다른 OS를 사용하는 경우 트러스 또는 strace 대신 다른 유사한 유틸리티를 사용해야 할 수도 있습니다)
(csh / tcsh 파생 쉘을 사용하는 경우 다른 방향 재 지정 명령문이 필요할 수 있습니다)
답변
빠른 업데이트, 다른 이유로 서버를 교체해야했습니다. 파일 시스템이었습니다. 모든 것이 잘되었습니다! 모두 감사합니다.
답변
핵 이론은 흥미롭지 만 대안적인 이론이 있습니다. 유닉스 파일 삭제 시맨틱은 모든 프로세스가 그것을 가리키는 열린 파일 핸들을 닫을 때까지 파일을 유지합니다. 누군가가 SVN 체크 아웃 / 커밋을 일시 중지했거나 서버 스레드가 중단되었을 수 있습니다. SVN 프로세스 (또는 Apache)를 다시 시작하면 문제가 해결되면 여기서 책임을 져야합니다.
아마도이 파일을 여전히 사용하여 프로세스를 식별 할 수 lsof | grep 6535있습니까?