Bug#292856: kernel-image-2.6.8-2-686: unkillable process
Unexpectedly, it is reproducible.
Here's the relevant bit of ps -e -F . This was taken
a minute or so after I started the strace find .
gpk 16650 16555 0 646 1480 0 20:35 pts/7 00:00:00 bash
gpk 16659 16650 1 428 572 0 20:36 pts/7 00:00:01 strace
find . -name #cvs
gpk 16660 16659 0 382 444 0 20:36 pts/7 00:00:00 find .
-name #cvs
gpk 16681 16583 0 624 852 0 20:38 pts/4 00:00:00 ps -e -F
/var/log/dmesg and /var/log/syslog show no relevant entries
(and no entries at all since I started the find .)
The directory from which I launched find
is on a local disk; no disks are configured for NFS.
The directory was reached via a symbolic link, though that
ought not to be relevant.
The disk it is on is the main system disk, and it seems
to be functioning well.
The tail end of the output of strace follows:
getdents64(4, /* 113 entries */, 4096) = 4072
getdents64(4, /* 50 entries */, 4096) = 1760
getdents64(4, /* 0 entries */, 4096) = 0
close(4) = 0
chdir("22") = 0
lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
chdir("..") = 0
lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("23", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
open("23", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4,
(The output stopped half-way through the last line.
I had it going directly to a terminal, rather than a file
to avoid any buffering.)
Horms wrote:
On Sun, Jan 30, 2005 at 03:06:43PM +0000, Greg Kochanski wrote:
Package: kernel-image-2.6.8-2-686
Version: 2.6.8-12
Severity: normal
A process hung, and was not killable, even with kill -9.
The process was started as
find . -name '#cvs*'
Here's an attempt to kill it:
It is probably not killable because it is probably stuck in the kernel
waiting for IO for some reason. Could you please examine dmsg to
see if there is anything useful there. Perhaps it is trying to
access an nfs partition that is unavailable, or some hardware that
has errors.
If you run the same command on the command line, possibly through
strace, it might shed some light on just where in the filesystem it is
getting stuck.
Reply to: