Anyone?

I am seeing something odd in some tusc output:

Tue Sep 2 16:31:17 2003 Received signal 20, SIGVTALRM, in open(),
[caught], no siginfo
Tue Sep 2 16:31:17 2003
open("/opt/dcelocal/var/security/creds/dcecred_0a9cd41d.data.db",
O_RDWR, 0600) = 25
Tue Sep 2 16:31:17 2003 gettimeofday(0x7f75cef0, 0x404b4e18) .... = 0
Tue Sep 2 16:31:17 2003
open("/opt/dcelocal/var/security/creds/dcecred_0a9cd41d.data.db",
O_RDWR|O_CREAT|O_EXCL, 0600) = 25
.....
Tue Sep 2 16:31:19 2003 close(25) ............................... = 0


To state the obvious, there are 2 opens giving the same file descriptor
on the same file with no intervening close.
The program being traced is dced which is multi threaded. I should have
used the "-u" option to print the thread id but assuming the timestamps
are correct I have ruled out multi threading issues (though I should do
this anyway when I get another window).

So some questions. Can there be an implicit close on an FD? That is,
might the kernel have closed the FD itself possibly as a result of the
signal after the first open? That would at least explain why there is no

close in the trace and how the kernel returns FD 25 again.

This occured on:
HP-UX xxxxxx B.11.00 A 9000/859

PS: The filesystem is suspected to be corrupt!

Adam.