During an online backup, db2vend process is forked from db2sysc
to process the backup request. Depending on platforms, this
forked process may inherit socket descriptors from db2sysc.
When db2sysc attempts to close the socket to terminate an
application, if that particular socket had been inherited to
db2vend, the socket will remain until db2vend terminates.
Hence, the application may seem hanging till the backup
completes. Note that all operations will resume correctly when
the backup completes.
Here's the example stack of an application in this state.
ffffffff7c1d2c40 recv (8, fffffffddb81ffe0, ffff, 0)
fffffffdde91f5f8 sqlccrecv (fffffffddc021260, 10004, 0,
ffffffff7fffe79c, 0, 90) + 310
fffffffddeb46654 __1cMsqljcReceive6FpnKsqljCmnMgr__i_
(fffffffddb808788, 0, 1, 1, 0, 1) + 14c
fffffffddeb9efe0
__1cVsqljrDrdaArDisconnect6FpnOdb2UCinterface__i_
(fffffffddc03ebd0, 0, 0, fffffffddb808320, fffffffddb808320,
fffffffddf163e58) + 5f0
fffffffdde9cc9e0 sqleUCdisconnect (fffffffddc03f960, 19a00000,
7974f4, 0, 0, fffffffddf163e58) + 80
fffffffdde9cc678 sqleUCappConnectReset (fffffffddc03f960,
fffffffddc030a2c, fffffffffffbffff, 0, 1, 0) + 220
fffffffdde415094
__1cRCLI_sqlDisconnect6FpnPCLI_CONNECTINFO_pnFsqlca_pnTCLI_ERROR
HEADERINFO__h_ (fffffffddc030080, fffffffddc030a2c,
fffffffddc030180, 252a8, 2a, 1304) + 1ac
fffffffdde3e00ec SQLDisconnect (fffffffddc030180, 1, 1000,
fffffffddf163e58, fffffffddc030080, fffffffddf1a88d8) + 8e4
<snipped...>
Solaris is most likely to experience this problem. HP is
somewhat vulnerable as well. Linux is highly unlikely, but
there is still a possibility, however small it may be. The fix
for this problem will prevent descriptors from being inherited. |
