Почему этот файл скрыт при запуске ls?

10

РЕДАКТИРОВАТЬ: Я полностью забыл об этой теме. Оказывается, у меня был плохой жесткий диск. Нам пришлось повторно развернуть этот сервер для других нужд, поэтому я наконец нашел способ заменить один неисправный диск, и мы снова в работе.

В течение нескольких недель я не мог понять, почему я не смог удалить этот конкретный файл. От имени root я могу, но мой скрипт запускается от имени другого пользователя. Итак, я бегу ls -la, а его там нет. Однако, если я назову это параметром, он появится! Конечно, владелец - root, поэтому я не могу удалить.

Обратите внимание, 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 принадлежит пользователю root. Файл фактически появляется после того, как я запускаю «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
linux command-line-interface shell luckytaxi
источник
2
Если вы выясните это, пожалуйста, разместите обновление.
einstiien
Интересно. что сообщается с ls -ab? Может быть, в имени файла есть какой-то странный не восьмеричный символ? Я бы подумал - я бы все равно это перечислил, но я не уверен.
egorgry
1
Вы недавно запускали fsck? Удаленно возможно что-то сломано в файловой системе.
Зоредаче
Завтра мне придется проверить это снова, уезжая на день.
luckytaxi

Ответы:

7

Это немного беспокоит. Я бы проверил, что ваш lsфайл не был изменен по сравнению с известным хорошим файлом. Вы можете использовать инструменты пакета вашего дистрибутива для проверки файла в изолированной системе.

сигнализатор
источник
+1: ls -al должен показать все. Если это не так, то есть проблема где-то.
Satanicpuppy
2
Вполне возможно, что lsэто было изменено, чтобы скрыть определенный PID, возможно,
6535.
Нет ... ничего ...
luckytaxi
6

Иногда имена файлов получают странные символы, такие как последовательности перемещения курсора. Попробуйте это, чтобы убедиться:

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

чтобы увидеть, определен ли псевдоним или функция, или посмотреть, находится ли двоичный файл в нечетном месте или был изменен.

Приостановлено до дальнейшего уведомления.
источник
1
+1 хорошее понимание. Важно отметить, что, если бы они lsбыли изменены, md5sumсистема также могла бы быть изменена. Вам нужна известная нормальная среда, чтобы проверить, чтобы прийти к окончательному выводу.
Warner
Я обнаружил, что даже если md5 был изменен для получения поддельных результатов, если вы делаете такие вещи, как «файл md5», вы все равно можете получить хорошие результаты (если программа md5 вообще работает), выполнив что-то вроде bzip2 <file | md5 и сравните это с той же командой в другом месте.
Крис
3

Вы можете хотеть fsck тот объем.

Флорин андрей
источник
13
это то, что она сказала.
einstiien
2

Я обычно делаю что-то подобное, если считаю, что «ls» был изменен ...

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

Конечно, Python, библиотека C, ядро ​​или файловая система также могут быть изменены, но обычно это просто утилиты оболочки.

McJeff
источник
2
Или вы можете использовать расширение имени оболочки для чтения каталога - echo * (а если хотите все, echo *. *)
chris
*.*только покажет вам файлы, которые имеют символы, за которыми следуют точка и символы. Это определенно не все в системе * nix. Я не уверен, что эхо покажет вам все в одной команде, я смог это сделатьecho * && echo .*
einstiien
4
Если вы посмотрите внимательно, это * (пробел). *, А не *. * Пунктуация не является сильной стороной этой системы комментирования ... И, echo совершенно счастлив расширить столько выражений, разделенных "$ IFS", сколько Вы хотите кормить его. Логическое && не является обязательным или даже имеет большой смысл, потому что && является логическим значением и всегда будет работать, потому что команда echo всегда успешна.
Крис
@ Крис: мой плохой, очень трудно это увидеть.
einstiien
2

Вы можете посмотреть, что именно делает ls, используя strace, и это может сказать вам, почему он не показывает это имя файла.

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

будь осторожен, ты был ранен ...

Это не окончательный тест, но это хороший показатель ...

(если вы используете Solaris или другие ОС, вам может потребоваться использовать ферму или другую аналогичную утилиту вместо strace)

(если вы используете производную от csh / tcsh оболочку, вам, вероятно, потребуются другие операторы перенаправления)

Крис
источник
Мне это нравится. straceУтилита действительно является швейцарским армейским ножом. Вы получаете право на уровень системных вызовов и обходите целую кучу произвольных усложнений. Это одна из первых вещей любого системного администратора. Стоит копейки на свалку на недавно установленной машине.
МакДжефф
Да, два наиболее ценных инструмента для системного администратора - это truss / strace и tcpdump. С их помощью вы всегда можете заглянуть под прикрытие, чтобы увидеть, что происходит wtf, когда что-то идет или не ведет себя так, как вы ожидаете.
Крис
2

Быстрое обновление, нам пришлось заменить сервер по другим причинам. Это была файловая система. Теперь все хорошо !!! Спасибо всем.

luckytaxi
источник
Вы имеете в виду, что файловая система была испорчена, и это был просто дурацкий симптом?
Крис
да это было это.
luckytaxi
Вы, вероятно, могли бы застревать в правке, чтобы сказать, что есть решение в списке ниже, так как оно было похоронено под другими ответами (и полезными для устранения неполадок).
Барт Сильверстрим
0

Теория взлома интересна, но у меня есть альтернативная теория. Семантика удаления файлов Unix будет держать файл до тех пор, пока все процессы не закроют открытые дескрипторы файлов, указывающие на него. Возможно, кто-то приостановил проверку / принятие SVN, или серверный поток завис. Если перезапуск SVN-процесса (или Apache) решит вашу проблему, я бы возложил вину на это.

Возможно, вы можете идентифицировать процесс, все еще используя этот файл lsof | grep 6535?

jldugger
источник
да lsof ничего не показывал Интересно, что 6535 также «отсутствует» в источнике. Мой скрипт выполняет горячую копию исходного репо в другой каталог. Именно тогда у меня возникли проблемы с невозможностью удалить этот конкретный файл по какой-то причине.
luckytaxi
Удаленный, но открытый файл не помешает вам удалить содержащий каталог, потому что, как только эта запись каталога будет удалена, запись каталога не будет существовать, поэтому каталог будет пустым. Вы не получите обратно пространство из файла, пока не будет уничтожен процесс, в котором он открыт, но каталог, в котором был этот файл, теперь можно удалить.
Крис
Ваша альтернативная теория интересна. Удаление в случае успеха мгновенно удалит жесткую ссылку. Inode, вероятно, все еще будет содержать данные, и некоторые файловые дескрипторы могут кэшировать их в памяти, но я не верю, что этот сценарий может объяснить описанное поведение. Или, что сказал Крис, хе.
Warner