Pourquoi ce fichier est-il masqué lorsque vous exécutez ls?

10

EDIT: J'ai totalement oublié ce fil. Il s'avère que j'avais un mauvais disque dur. Nous avons dû redéployer ce serveur pour d'autres besoins, j'ai donc finalement pu remplacer le seul disque défectueux et nous sommes de retour aux affaires.

Depuis quelques semaines, je ne pouvais pas comprendre pourquoi je ne pouvais pas supprimer ce fichier en particulier. En tant que root, je peux, mais mon script shell s'exécute en tant qu'utilisateur différent. Je lance donc ls -la et ce n'est pas là. Cependant, si je l'appelle comme paramètre, il apparaît! Effectivement, le propriétaire est root, donc je ne peux pas supprimer.

Remarquez, 6535 est manquant ...

[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

Maintenant, il apparaît si vous l'appelez directement.

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

Voici quelque chose d'intéressant. J'ai donc détecté ce problème car dans mon script shell, il ne pourrait pas être supprimé car 6535 appartient à root. Le fichier apparaît en fait après avoir exécuté "rm -rf". Je l'ai essayé plus tôt et il n'a pas pu supprimer le répertoire car il m'a dit que le répertoire n'était pas vide. Je suis entré et j'ai regardé et bien sûr, le fichier "6535" apparaît enfin. Je ne sais pas pourquoi ça fait ça.

strace dit le texte suivant

#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
source

2

Si vous comprenez cela, veuillez publier une mise à jour.

— einstiien

Intéressant. qu'est-ce qui est signalé avec ls -ab? Peut-être qu'un caractère étrange non octal se trouve dans le nom du fichier? Je penserais -a l'énumérerait de toute façon mais je ne suis pas sûr.

— egorgry

1

Avez-vous récemment exécuté un fsck? Il est possible à distance que quelque chose soit cassé sur le système de fichiers.

— Zoredache

Je devrai le tester à nouveau demain, en partant pour la journée.

— luckytaxi

7

C'est un peu inquiétant. Je vérifierais que votre lsfichier n'a pas été modifié en le comparant à un bon fichier connu. Vous pouvez utiliser les outils de package de votre distribution pour vérifier le fichier sur un système isolé.

— Warner
source

+1: ls -al devrait tout montrer. Si ce n'est pas le cas, il y a un problème quelque part.

— Satanicpuppy

2

Il est fort possible qu'il lsait été modifié pour masquer un PID spécifique, peut-être 6535.

— MikeyB

Non ... rien ...

— luckytaxi

6

Parfois, les noms de fichiers contiennent des caractères étranges tels que des séquences de mouvement de curseur. Essayez ceci pour vous assurer:

ls -lq

Il devrait afficher des points d'interrogation au lieu de caractères de contrôle (c'est probablement la valeur par défaut, mais ce n'est peut-être pas le cas).

Cela montre partiellement le type de problème qui peut être présent:

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

J'essaierais aussi:

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

pour voir si un alias ou une fonction est définie ou pour voir si un binaire est dans un endroit impair ou a été modifié.

— En pause jusqu'à nouvel ordre.
source

1

+1 bon aperçu. Il est important de noter que s'il lsavait été modifié, le md5sumsur le système aurait également pu être modifié. Vous avez besoin d'un environnement sain connu pour vérifier pour arriver à une conclusion définitive.

— Warner

J'ai trouvé que même si md5 a été modifié pour produire de faux résultats si vous faites des choses comme «fichier md5», vous pouvez toujours obtenir de bons résultats (si le programme md5 fonctionne) en faisant quelque chose comme bzip2 <fichier | md5 et comparer cela à la même commande ailleurs.

— chris

3

Vous pouvez vouloir fsck ce volume.

— Florin Andrei
source

13

c'est ce qu'elle a dit.

— einstiien

2

Je fais habituellement quelque chose comme ça si je crois que 'ls' a été modifié ...

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

Bien sûr, Python, la bibliothèque C, le noyau ou le système de fichiers peuvent également être modifiés, mais généralement ce ne sont que les utilitaires du shell.

— McJeff
source

2

Ou, vous pouvez utiliser l'extension du nom de fichier du shell pour lire le répertoire - echo * (et si vous voulez tout, echo *. *)

— chris

*.*ne va vous montrer que les fichiers qui ont des caractères suivis d'un point suivi de caractères. Ce n'est certainement pas tout sur le système * nix. Je ne suis pas sûr que l'écho vous montrera tout en une seule commande, j'ai pu le faireecho * && echo .*

— einstiien

4

Si vous regardez attentivement, c'est * (espace). *, Pas *. * La ponctuation n'est pas le point fort de ce système de commentaires ... Et, l'écho est parfaitement heureux d'étendre autant d'expressions séparées par le "$ IFS" que vous vous souciez de le nourrir. Le booléen && n'est pas nécessaire, ou n'a même pas beaucoup de sens, car && est un booléen et fonctionnera toujours parce que la commande echo est toujours réussie.

— chris

@chris: ma mauvaise, vraiment difficile de voir ça.

— einstiien

2

Vous pouvez regarder exactement ce que fait ls en utilisant strace, et cela peut vous expliquer pourquoi il évite d'afficher ce nom de fichier.

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

regardez cela à travers cela et voyez ce qui se passe.

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

La sortie ressemblera à ceci:

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

et si vous voyez quelque chose comme

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

soyez prudent, vous avez été 0wned ...

Ce n'est pas un test concluant, mais c'est un bon indicateur ...

(si vous utilisez Solaris ou d'autres systèmes d'exploitation, vous devrez peut-être utiliser Truss ou un autre utilitaire similaire au lieu de Strace)

(si vous utilisez un shell dérivé de csh / tcsh, vous aurez probablement besoin de différentes instructions de redirection)

— chris
source

J'aime ça. L' straceutilité est vraiment un couteau suisse. Vous accédez directement au niveau d'appel système et contournez toute une pile de complications arbitraires. C'est l'une des premières choses que n'importe quel administrateur système. vaut un sou devrait vider sur une machine nouvellement installée.

— McJeff

Oui - les deux outils les plus précieux pour un administrateur système sont truss / strace et tcpdump. Avec ceux-ci, vous pouvez toujours regarder sous les couvertures pour voir que wtf se passe quand quelque chose se comporte ou ne se comporte pas comme vous l'attendez.

— chris

2

Mise à jour rapide, nous avons dû remplacer le serveur pour d'autres raisons. C'était le système de fichiers. Tout va bien maintenant !!! Merci tout le monde.

— luckytaxi
source

Vous voulez dire que le système de fichiers a été foiré et que c'était juste un symptôme farfelu?

— chris

ouais c'était ça.

— luckytaxi

Vous pourriez probablement avoir bloqué dans une modification pour dire qu'il y a une solution dans la liste ci-dessous, car elle a été enterrée sous d'autres réponses votées (et utiles pour le dépannage).

— Bart Silverstrim

0

La théorie du hack est intéressante, mais j'ai une théorie alternative. La sémantique de suppression de fichiers Unix conservera le fichier jusqu'à ce que tous les processus aient fermé les poignées de fichier ouvertes pointant dessus. Peut-être que quelqu'un a suspendu une extraction / validation SVN, ou un thread de serveur a raccroché. Si le redémarrage du processus SVN (ou Apache) résout votre problème, c'est là que je blâmerais.

Peut-être pouvez-vous identifier le processus utilisant toujours ce fichier avec lsof | grep 6535?

— jldugger
source

oui lsof n'a rien montré. La chose intéressante est que 6535 est également "manquant" dans la source. Mon script fait une copie à chaud du dépôt d'origine dans un autre répertoire. C'est alors que j'ai rencontré des problèmes avec le fait de ne pas pouvoir supprimer ce fichier particulier pour une raison quelconque.

— luckytaxi

Un fichier supprimé mais ouvert ne vous empêchera pas de supprimer le répertoire contenant car une fois cette entrée de répertoire supprimée, l'entrée de répertoire n'existera plus, le répertoire sera donc vide. Vous ne récupérerez pas l'espace du fichier tant que le processus qui l'a ouvert n'est pas tué, mais le répertoire qui contenait ce fichier peut maintenant être supprimé.

— chris

Votre théorie alternative est intéressante. La suppression, si elle réussit, supprimera instantanément le lien dur. L'inode contiendrait probablement toujours les données et certains descripteurs de fichiers peuvent les avoir mis en cache en mémoire, mais je ne pense pas que ce scénario pourrait expliquer le comportement décrit. Ou, ce que Chris a dit, heh.

— Warner