Kbase 21142: Semaphore id's locked when working with multiple DBs
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  7/1/2004 |
|
Status: Unverified
SYMPTOM(s):
Working with multiple databases, the semaphore id's get locked by the process.
This can occur even if the database is shut down.
Semaphore id was removed (1075)
Invalid semaphore id (1132)
SYSTEM ERROR: unable to <acc/cr> semaphore set <db>:<ch>, errno <n>. (551)
CAUSE:
In this case there is a conflict on the use of the resources. Once Database 1 was started the biw sent the error (1075), followed by the Server disconnection, and finally the error (1132) showing the invalid semaphore id by watchdog process.
-- Database 1
10:26:20 APW 5: Started. (2518)
10:26:20 APW 6: Started. (2518)
10:26:20 APW 7: Started. (2518)
10:26:30 BIW 3: Semaphore id 2 was removed (1075)
10:26:30 AIW 2: Semaphore id 2 was removed (1075)
10:26:30 AIW 2: ** The server has disconnected. (723)
10:26:30 BIW 3: ** The server has disconnected. (723)
10:27:01 WDOG 1: Disconnecting dead user 2. (2527)
10:27:01 WDOG 1: Invalid semaphore id (1132)
10:27:01 WDOG 1: SYSTEM ERROR: unable to get value of semaphore set :°, errno 22. (551)
10:31:13 BROKER 0: Broker could not spawn a server. (1157)
Almost simultaneously the second database that is already working, starts sending the message (1132), an invalid semaphore id, followed by the error (551), unable to get value of semaphore set.
-- Database 2
09:44:08 Usr 4: Login by reh76555 on /dev/ttyp11. (452)
09:44:16 Usr 4: Userid is now reh76555. (708)
10:26:28 Usr 8: Login by reh76559 on /dev/ttyp0. (452)
10:32:03 Usr 8: Invalid semaphore id (1132)
10:32:03 Usr 8: SYSTEM ERROR: unable to set semaphore set :Ì, errno 22. (551)
10:32:03 Usr 8: Logout by on /dev/ttyp0. (453)
10:32:03 Invalid semaphore id (1132)
10:32:03 SYSTEM ERROR: unable to get value of semaphore set :Ì, errno 22. (551)
10:55:13 Usr 9: Login by reh76095 on /dev/ttyp1. (452)
10:55:17 Usr 9: Semaphore id 2 was removed (1075)
11:03:05 Usr Logout by on /dev/ttyp1. (453)
At the beginning it seems there is a lack of resources. But if the databases were working with the same kernel parameters and there were no changes, it looks like there is a conflict in the use of the semaphores between these two databases.
FIX:
One solution is to shutdown both databases and truncate the bi for both. Usually this truncation completes normally, but if it becomes necessary, use the -F.
If the truncation does not fix the problem, a second suggestion is to use ipcs -s to locate the semaphores the databases are using. Then shutdown the databases and make sure the semaphore's id's are not still attached to any process. If this is the case, use ipcrm -s id.
A third option is to increase the kernel parameters regarding semaphores.