Kbase 13790: User died holding shared memory or buffer latch / lock
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
User died holding shared memory or buffer latch / lock
When a user connects to a Progress database in multi-user mode, the
user control table in shared memory is updated to add the user.
The Progress watchdog (in 6.3+), or the server if no watchdog is
running, periodically check to make sure that all users listed in the
user control table have corresponding UNIX processes running.
If the watchdog or server detect that a user is listed in the Progress
user control table but does not have an active UNIX process, the
user will be disconnected from the Progress database and the
following message will be written to the log file:
Disconnecting dead user . (2527)
If the user's process terminated abnormally while holding latches
(locks) in shared memory, a message similar to the two shown below
will be written to the log file:
User died holding shared memory locks. (2522)
User died with buffers locked. (2523)
If shared memory or buffer latches are left in an inconsistent state,
the server will shutdown the database to protect the integrity of the
database. The following message will be written to the log file
followed by all users being logged out and the server shutting down:
Begin ABNORMAL shutdown code x (2249)
[NOTE: the code number in the message above is for future use and
currently has no meaning.]
The error does not indicate any data corruption. Rather, the
shutdown occurs to prevent any possibility of corruption. Upon
re-starting the database, crash recovery will be done and the database
will be ready for normal use.
In addition to the above errors, the following messages may be
written to the .lg file as the abnormal shutdown proceeds and logs out
all the users:
System Error: redundant lwake user <n> latch <x>
This error also does not indicate database corruption.
Events that could cause a process to terminate abnormally include:
1. sending a kill signal (other than SIGHUP) to the process
2. shutting off a terminal while in an active Progress session and the
terminal (tty or PC with terminal emulation) does not send a SIGHUP
3. the process aborting as a result of a system error.
NOTE: Workaround below should only be needed in any version 6 less
than 6.3F plus the latest patch and in version 7.2. The signal
handling in PROGRESS has been improved to include many more
signals. If this error occurs repeatedly in one of the later
PROGRESS versions, it is important to determine what is causing
the user process to die and try to resolve that problem. It is
also important to note that if this error occurs frequently on
an older version of PROGRESS, it is recommended to install the
latest version available on that platform.
For those sites where this occurs frequently, a way to prevent an
abnormal shutdown is to run all users as "remote" clients even if they
are logging in directly to the machine where the database is. In this
way, the user processes do not access shared memory directly. Instead
they connect to a server process which accesses shared memory. The
server process obtains shared memory and buffer latches for the user
process and so if the user process abnormally terminates, the server
process is still running and can clean up any remaining latches.
Ex: 1) start server with network parameters:
proserve demo -S demosv -H myhost
2) start user session as local "remote" client from same machine:
mpro demo -S demosv -H myhost
FEB-07-1995
Progress Software Technical Support Note # 13790