Lock remains after killing a client

[Chris Schippers]

Sometimes when a Progress Session Hangs (or windows session) a client has to be killed using the task manager (or rebooting).

Now I have the problem that sometimes the Progress client is not killed and keeps a record locked. Even after rebooting the database reports that the user is still logged in and the lock remains.

I tried to kill the user using proshut. The user is removed from the list within proshut, but when I look with promon the user and lock are still there.

Does anybody know how I can get rid of the user and the lock withouth restarting the complete database?

Thanks.

 

[Unregistered]

That sounds "very" nasty .. what version of Progress and patch level is it??

 

[jongpau]

Do you also start Progress "Watchdog(s)" on your database(s)? These should normally clean up things when a client 'dies' unexpectedly.

According to the Progress documentation: "Progress Watchdog (WDOG). The watchdog process cleans up after improperly terminated processes by releasing locks, backing out any live transactions and releasing shared-memory locks, and disconnecting and cleaning up the server's remote clients."

See "Database Administration Guide and Reference" for more info.

HTH.

 

[MurrayH]

The version and patch level as well as the exact OS (including service packs) would help.

 

[Chris Schippers]

I will try to start the watchdog as soon as we have the problem again, see if it helps.

The problem occurs in 9.1a to 9.1b. 9.1c is not at our clients yet, so i have no idea if the problem still occurs.

 

[jongpau]

Chris,

You should start the Watchdog before you have the problem. It will run in the background (and be connected to your database) and should then automatically clean up when a client dies (at least, that's the theory)...
I always have a Watchdog running. My Progress sessions hang frequently (espacially lately and I have not found out why yet), but I never have any dead clients hanging around in my database making my life more difficult.

Anyway, it's just a thought

 

[Calvin Crawford]

Chris,

You should start the Watchdog before you have the problem. It will run in the background (and be connected to your database) and should then automatically clean up when a client dies (at least, that's the theory)...
I always have a Watchdog running. My Progress sessions hang frequently (espacially lately and I have not found out why yet), but I never have any dead clients hanging around in my database making my life more difficult.

Anyway, it's just a thought

I am having this problem, too. And WDOG is running. OE 10.1c on HPUX 11

 

[TomBascom]

You're rebooting HPUX and restarting the server and your database still has locks in it?

WDOG checks that users in the database have corresponding processes running on the OS. It will only do this for self-service sessions. If you are starting sessions with -S WDOG will not clean them up. Even if they are on the same server.

This thread seems to describe a situation where remote clients are aborting and being rebooted. Typically when this happens the Progress server doesn't know about it -- the client just stops making requests. If the client had resources locked they remain locked until something occurs which would clear them. Often the first even that cleans them up is the expiration of the TCP_KEEPALIVE timer. This is an internal feature of the TCP/IP protocol that detects broken connections at the IP layer. Unfortunately the default interval is a bit more than 2 hours.

 

[Calvin Crawford]

no... the server has not been rebooted, nor has the db been bounced. The users' connections were lost, but their sessions remained active with locked records. The sessions were subsequently removed using proshut. The records remained locked for several hours. Prior to "upgrading" to OE the locks would have been removed as soon as the sessions were terminated.

 

[TomBascom]

Have you reported it to tech support?

 

[taqvia]

what about keepalive time value ?

 

[Calvin Crawford]

Have you reported it to tech support?

of course...however we have to go through our application provider. Anyways, it appears that it took about an hour and a half for the session to fully accept the signal 7 that proshut had sent. Though the session was no longer visible in proshut, it had not fully been terminated. This happened on two separate databases yesterday.

 

[Calvin Crawford]

what about keepalive time value ?

do you know where to find documentation for it?

 

[TomBascom]

of course...however we have to go through our application provider. Anyways, it appears that it took about an hour and a half for the session to fully accept the signal 7 that proshut had sent. Though the session was no longer visible in proshut, it had not fully been terminated. This happened on two separate databases yesterday.

What does "not fully terminated" look like? Do you see something revealing in PROMON (perhaps in "user control" or the lock table screens?) or in the .lg file?

 

[TomBascom]

TCP Keepalive details vary by OS. Google "TCP Keepalive HPUX" and you'll get lots of information.

 

[Calvin Crawford]

What does "not fully terminated" look like? Do you see something revealing in PROMON (perhaps in "user control" or the lock table screens?) or in the .lg file?

Record Locking Tables in promon showed that the session had record locks in place.

logfile entries as follows. Immediately after disconnecting the session in proshut, it was no longer visible within proshut.

[2008/07/08@08:47:06.537-0700] P-15815 T-1 I SHUT 129: (-----) User 101 disconnect initiated
[2008/07/08@08:47:06.538-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:47:42.607-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:47:49.374-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:47:58.321-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:48:06.719-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:48:16.519-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:48:22.707-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:48:44.320-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@08:48:51.411-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@09:40:58.792-0700] P-26916 T-1 I BROKER 0: (-----) Sending signal 7 to user 101
[2008/07/08@10:25:30.101-0700] P-21219 T-1 I ABL 101: (562) HANGUP signal received.

 

[TomBascom]

I would be very curious to see what those lock table screens look like.

Have you double checked to make sure that you are not trapping signals?

 

[Calvin Crawford]

I've replicated the situation in a test environment...my appologies for the table formatting.... there are no flags on either of the locks. Anyway, the only thing different in this environment from the previous week is that we migrated to OE 10.1c from Progress 9.1e.

Record Locking Table:
Usr Name Chain # Rec-id Table Lock Flags Tran State
Tran ID
14 ccraw REC 18 51515137 39 EXCL Active
259371927
14 ccraw REC 1376 51578883 39 EXCL Active
259371927


usr pid time of login user id tty Limbo?
5 28054 Wed Jul 9 22:30:46 2008 APW no
6 28061 Wed Jul 9 22:30:46 2008 APW no
7 28065 Wed Jul 9 22:30:46 2008 APW no
8 28071 Wed Jul 9 22:30:46 2008 APW no
9 28080 Wed Jul 9 22:30:46 2008 BIW no
10 28086 Wed Jul 9 22:30:46 2008 WDOG no
11 28114 Wed Jul 9 22:30:48 2008 BATCH batch no
12 4140 Wed Jul 9 22:47:18 2008 FINISHER batch no
13 4211 Wed Jul 9 22:47:20 2008 WSSTAGMK batch no

1 Disconnect a User
2 Unconditional Shutdown
3 Emergency Shutdown (Kill All)
x Exit

 

[TomBascom]

The transaction state is ACTIVE. Do you perhaps have a problem with long running open transactions?

Now I'm curious to see the "active transactions" screen.