On Wed, 2004-01-21 at 04:29, Joe Orton wrote: > > $ sudo strace -p 3850 > > trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted > > detach: ptrace(PTRACE_DETACH, ...): Operation not permitted > > Ah, add "CoreDumpDirectory /tmp" to your httpd.conf and make sure you're > running the latest errata kernel so that ptrace works properly...
Criminy, I'm testing on a server where I don't really have the ability to upgrade the kernel. It's a redhat 7.2 machine running kernel 2.4.20. I added the CoreDumpDirectory directive, but 'strace' still doesn't work correctly. > > I have now managed to reproduce hangs a couple of times here, What exactly was your reproduction recipe? Same as mine? Start an import over SSL and then 'graceful' the server? > only using > db-4.1.25 on the server: the child was sat eating CPU, either doing no > syscalls or doing: > > futex(0xbf58b1b0, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0xbf58b1b0, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0xbf58b1b0, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0xbf58b1b0, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > futex(0xbf58b1b0, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily > unavailable) > > ...which could be a db4 issue. Is that consistent with what you're > seeing with 4.2.52? I'm pretty ignorant about strace-y things. Why do you think this output is relevant to BDB? I wonder if the next step is to simply try reproducing the bug by running client and server both on my local box? (It's a RH9 box with the latest 2.4.20 kernel.)
