OpenEdge 10.2B0832, Linux SUSE 11 SP3 64-bit
Session hung in the middle of transaction – its last notes before hang:
RL_RMCHG RL_TMSAVE RL_TMSAVE RL_TMSAVE RL_CXREM RL_CXREM RL_CXINS RL_CXINS RL_TMSAVE RL_TMSAVE
Proshut disconnect did not work. Session also ignored the signals (including SIGUSR1). Db activity of the session was not changing.
Linux strace command said:
Trace of process 27517 - /usr/dlc/bin/_progres [snip] Process 27517 attached - interrupt to quit futex(0x7fbd3952da54, FUTEX_WAIT_PRIVATE, 2, NULL
The futex() system call provides a method for waiting until a certain condition becomes true. It is typically used as a blocking construct in the context of shared-memory synchronization. When using futexes, the majority of the synchronization operations are performed in user space. A user-space program employs the futex() system call only when it is likely that the program has to block for a longer time until the condition becomes true. Other futex() operations can be used to wake any processes or threads waiting for a particular condition.
I guess the session was waiting for something that is NOT related to the database. What it can be?
Finally the session was killed using kill -9 and the database kept running:
[2017/02/03@18:22:25.810+0600] P-20614 T-140479547926272 I WDOG 8: (2527) Disconnecting dead user 195. [2017/02/03@18:22:25.810+0600] P-20614 T-140479547926272 I WDOG 195: (2252) Begin transaction backout. [2017/02/03@18:22:25.861+0600] P-20614 T-140479547926272 I WDOG 195: (2253) Transaction backout completed.
futex’es are used by various functions in the C runtime library.
they are also used by various mutex functions in the posix thread library.
without the rest of the stack trace, we can’t tell what called it.
Thnaks, Gus. So we can't guarantee the 100% safety when using kill -9 against a process in FUTEX_WAIT, can we?