Вопросы Теги

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

Большинство клиентов будет работать с TTL, который Вы устанавливаете. Однако существуют некоторые серверы DNS, которые настроены для игнорирования TTL. Я недавно изменил IP-адреса наших веб-сайтов. Мы должны были оставить на виду серверы и работу старых IP-адресов в течение многих недель для ответа на запросы. Мы точно должны были выяснить остающихся клиентов и запросить, чтобы они убрали там кэш DNS и/или перезагрузку для получения их от старого дюйм/с.

10
задан 27 December 2011 в 18:28
7 ответов

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

2
ответ дан 2 December 2019 в 22:02
  • 1
    Вы подразумеваете, что файловая система была завинчена, и это было просто дурацким признаком? –  chris 28 April 2010 в 23:12
  • 2
    да это было этим. –  luckytaxi 10 May 2010 в 21:52

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

7
ответ дан 2 December 2019 в 22:02
  • 1
    +1: ls - al should показывает все. Если это doesn' t где-нибудь существует проблема. –  Satanicpuppy 26 March 2010 в 19:46
  • 2
    It' s довольно возможный, что ls был изменен для сокрытия определенного PID, возможно 6535. –  MikeyB 26 March 2010 в 20:38
  • 3
    Нет... ничто... –  luckytaxi 26 March 2010 в 21:44

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

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

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

6
ответ дан 2 December 2019 в 22:02
  • 1
    +1 хорошее понимание. It' s важный, чтобы отметить, что, если ls были изменены, md5sum в системе, возможно, был потенциально изменен также. Вам нужна известная нормальная среда для проверки на сделать категорический вывод. –  Warner 26 March 2010 в 20:47
  • 2
    I' ve нашел что, даже если md5 был изменен для приведения к поддельным результатам, если Вы делаете вещи как ' md5 file' можно все еще получить хорошие результаты (если md5 программа работает вообще) путем выполнения чего-то как bzip2 < файл | md5 и выдерживает сравнение что к той же команде в другом месте. –  chris 28 March 2010 в 16:02

Я обычно делаю что-то вроде этого, если я полагаю, что 'ls' был изменен...

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

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

2
ответ дан 2 December 2019 в 22:02
  • 1
    Или, Вы могли использовать shell' s расширение имени файла для чтения каталога - отзываются эхом * (и если Вы хотите все, эхо *.*), –  chris 26 March 2010 в 21:36
  • 2
    *.* только собирается показать Вам файлы, которым следовала за символом (символами) точка, сопровождаемая символом (символами). Это определенно не, все на *отклоняет систему. I' m не верное эхо покажет Вам все в одной команде, я смог сделать это echo * && echo .* –  einstiien 26 March 2010 в 21:47
  • 3
    Если Вы смотрите тесно, это * (пространство).*, не *.* Пунктуация не сильная сторона этой системы комментария... И, эхо совершенно радо расшириться как много выражений, разделенных " $IFS" поскольку Вы хотите подать его. Булевская переменная & & не необходимо, или действительно даже имейте много смысла, потому что & & булевская переменная и и будет всегда работать, потому что команда эха всегда успешна. –  chris 26 March 2010 в 22:12
  • 4
    @chris: мое плохое, действительно трудно для наблюдения этого. –  einstiien 27 March 2010 в 00:22

Можно хотеть к fsck тот объем.

3
ответ дан 2 December 2019 в 22:02

Можно изучить точно, что 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

будьте осторожны, Вы были 0wned...

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

(при использовании solaris или другого OSs Вы, возможно, должны использовать связку или некоторую другую подобную утилиту вместо strace),

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

2
ответ дан 2 December 2019 в 22:02
  • 1
    Мне нравится это. strace утилита действительно является швейцарским ножом. Вы разбираетесь к уровню системного вызова и обходите целую груду произвольной сложности. It' s одна из первых вещей любой системный администратор. стоящий десяти центов должен вывести на недавно установленной машине. –  McJeff 26 March 2010 в 22:30
  • 2
    Да - два самых ценных инструмента для системного администратора являются связкой / strace и tcpdump. С ними Вы можете всегда взгляд под покрытиями, чтобы видеть, что wtf продолжается, когда что-то или isn' t поведение путем Вы ожидаете. –  chris 26 March 2010 в 22:52

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

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

0
ответ дан 2 December 2019 в 22:02
  • 1
    да lsof didn' t показывают что-либо. Интересная вещь, 6535 также " missing" в источнике. Мой сценарий делает hotcopy исходного repo к другому каталогу. That' s, когда я столкнулся с проблемами с неспособностью удалить этот конкретный файл по некоторым причинам. –  luckytaxi 26 March 2010 в 22:21
  • 2
    Удаленный, но открытый файл won' t мешают Вам удалять содержание каталога, потому что, после того как та запись каталога удалена, запись каталога won' t существуют так, каталог будет быть пустым. Вы won' t возвращают пространство из файла до процесса, который имеет его открытый, уничтожается, но каталог, который имел тот файл, может теперь быть удален. –  chris 26 March 2010 в 22:24
  • 3
    Ваша альтернативная теория интересна. Удаление, в случае успеха, немедленно удалило бы жесткую ссылку. inode, вероятно, все еще содержал бы данные, и некоторым дескрипторам файлов можно было кэшировать его в памяти, но я не полагаю, что этот сценарий мог объяснить описанное поведение. Или, что сказанный chris, heh. –  Warner 26 March 2010 в 23:03

Теги

Похожие вопросы