Kbase 17609: The Final Word On 1260 in Release 8.2A and Beyond
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/07/2005 |
|
Status: Unverified
FACT(s) (Environment):
Progress 7.x
Progress 8.2
UNIX
SYMPTOM(s):
Shared memory in use by another process. (1260)
CAUSE:
In Progress version 7.x, the problem was due to an issue with the system call ftok() with which Progress used filename and inode number to generate a "unique" shmid which is stored in the master block of the database. This posed a problem for databases sharing a common name or inode number across multiple file systems.
Another element to this problem has been the contrast between crashed databases and crashed systems. The crashed database will always retain its shared memory id in the master block when in a crashed state. This is not new news. We can clear it (prior to V8.2) with the startup single-user, shutdown, then restart in multi-user mode as we have documented earlier.
FIX:
For Progress 7.x
The workarounds for these problems are somewhat cumbersome as they often require shutting down and restarting potentially several databases or the moving of several files in an effort to "fake out" UNIX. Because we are often supporting customers in multi db or file system environments, it is not always easy to control the startup and shutdown sequences of all the databases. Nor is it possible to move these db files in order to get different inode numbers thus producing a different value for the shmid from the algorithm. There is no certifiable workaround that Progress Development provides in versions prior to 8.2. Several of the previous workarounds have been very successful, however we have seen this problem come up on multiple occasions and sometimes none of the conventional workarounds seem to work.
For Progress 8.2 and higher
What is new is that starting with Version 8.2, prostrct repair dbname (dbname.st optional) can be use to clear the shmid in the master block for a crashed db. This has been recommended in prior versions but has failed for single volume db's. This should work for both single volume and multi-volume db's in Version 8.2 and higher. We have recoded the prostrct repair utility to accommodate database quiet points in V8.2 which has facilitated this new workaround.