Hi,
We have an unusual problem with files that are invisible (sort of) to 'ls' and
other programs. This shows up when using the standard versions of these
programs that are shipped with Debian 'Woody' (up to date via
security.debian.org). However, the files are visible when using
statically linked versions of 'ls' such as that shipped with some ftp
servers. This has been happening sporadically on a couple of machines in
a couple of directories (all running Woody with updates from security).
For instance, in the directory:
/home/stampy/queues/sendsyphonemailqstore/q_dispatch
you can ls -la it, and find no files:
stampy:~# ls -la /home/stampy/queues/sendsyphonemailqstore/q_dispatch
total 8
drwxr-sr-x 2 louisb staff 4096 Jun 25 11:45 .
drwxr-sr-x 7 louisb staff 4096 Jan 4 14:05 ..
The log of the program which puts files in this directory gives us the
filenames of files that it has put in there. From this we can use the
dynamically linked version of 'ls' or 'find' or 'rm' to operate on the
file:
stampy:~# ls -la /home/stampy/queues/sendsyphonemailqstore/q_dispatch/1088004896841
-rw-r--r-- 1 louisb staff 1 Jun 24 01:34
/home/stampy/queues/sendsyphonemailqstore/q_dispatch/1088004896841
stampy:~#
However, when you just use the statically linked 'ls', it is able to
fully list the directory and its contents without explicitly naming the
files. I've tried the 'sash' (stand alone shell) that comes with woody,
and ships with statically linked 'ls' and 'find', but it preumably uses
the same libraries compiled into to each utility as the dynamic ones, as
it can't find the files unless named explicitly.
We have a lot of 'invisible' files in /tmp, which upon reboot, cannot
clean the directory as it complains about the directory not being empty.
We've used 'strace' and I haven't gained much insight from that that has
helped (maybe because I'm not good at reading the output of this
program). I've also used 'debugfs' which can find all the files fine.
If you 'vi' the directory in which the file is in, it does not show the
file name. And if you tar the directory, it will not find the file, but
if you use 'dump' it will (presumably because dump works on a lower
level, on filesystems or inodes).
The disks have all been force fsck'ed and no errors are found. More
information about the machines:
* Machine 1 running kernel 2.4.18 (source from security.debian.org, compiled
locally)
* Machine 2 running kernel 2.4.25 (source from kernel.org, compiled locally)
* Both have ext2
* libc-2.2.5.so
* gcc version 2.95.4 20011002 (Debian prerelease)
Other info:
stampy:~# ldd `which find`
libc.so.6 => /lib/libc.so.6 (0x40017000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
stampy:~# ldd `which ls`
librt.so.1 => /lib/librt.so.1 (0x40017000)
libc.so.6 => /lib/libc.so.6 (0x40028000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40146000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
It may not be glibc, but that is common to a lot of stuff.
On both machines, the problems are showing up in the /tmp/CGI_Cache
directory. The filesystems have not run out of inodes
Any ideas what could cause this? It has happened on a 3rd machine now
too. One of the machines uses hardware scsi RAID and the other two are
using IDE (different chipsets, one VIA, the other AMD).
I realise that a bug in glibc is pretty unlikely, but I'm not really
sure what else could be doing it and welcome further troubleshooting
suggestions.
Note: all the filenames have standard alphanumeric characters, do not
have any odd permissions like the immutable attribute etc...
Thanks for any pointers,
Campbell
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
