Kbase 17664: Different ipcs Output in Version 8 than Version 7
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
Different ipcs Output in Version 8 than Version 7
There has been a change in the system call for calculating the shared
memory identifier in version 8.0B and beyond.This is due to a change
from the ftok() system call to shmget, and all this is well documented
in KB 17521. One of the byproducts of this change is some differences
in ipcs output between version 7 and 8 databases, the specifics of
which will be covered in detail in this knowledgebase article.
With a server up and running on a version 7 database type the
following:
proutil -C dbipcs
Here is what you should get:
PROGRESS SHARED MEMORY STATUS
ID ShMemVer Seg# InUse Database
90122 7352 0 Yes abbot
Then from the UNIX prompt run the system's ipcs for just that
database's shared memory id:
ipcs |grep 90122 ---> yields the following:
m 90122 0x0016a112 --rw-rw-rw- damore ts
Notice the hexidecimal value. This is the shared memory key for this
database and under normal startup and shutdown circumstances this
value should be unique to this database. In version 7 this key is
generated by the system call ftok() which uses the project ID (char
value between 0 and 255) and a pathname. Because different files of
the same name can get the same value for the shared memory id if they
reside on different file systems, this poses a potential problem,
hence the change in the system call in version 8.0B+.
In 8.0B+ shmget is used as the system call for shmid's instead of
ftok(), and as a result shmget gets the value of this key from
IPC_PRIVATE. When IPC_PRIVATE gives shmget a value of 0, shmget will
recieve the next available shmid, or if none is available shmget will
fail altogether to eliminate conflicts.
What does all this mean for ipcs? If we run the same test as above
on a version 8.0B+ db we get the following for dbipcs:
8205 8204 0 Yes costello
If we then run the system's ipcs and grep for the ID we get the
following:
ipcs |grep 8205
m 8205 00000000 --rw-rw-rw- damore ts
The value that was represented in hexidecimal for the version 7
database is now represented by all zeros. This is because IPC_PRIVATE
gave the value of 0 to shmget() therefore will be getting the next
available key. ipcs is simply reporting the key (or indicator that we
will get the next available) as passed to it by IPC_PRIVATE.
Hopefully this explains the sudden emergence of zeros in the ipcs
field where a hexidecimal key used to be constantly displayed.
SDA 2/5/98
Progress Software Technical Support Note # 17664