For UniVerse on a *NIX box, check the terminal settings with "stty -a <
/dev/ptsnn" where the /dev value is a tty device. In a session, "stty -a"
will work. If you wish to see the settings for a hung process, use the
device shown on the "ls -l" command with the stty - < /dev/pts*nn*.
The parameters of interest are clocal and hupcl. The hupcl parameter
describes the response to the hangup signal (SIGHUP) or hang up on close.
If you see hupcl, then the hangup signal is passed to the application. If
you see -hupcl, the environment will suppress passing the hangup signal to
the process and the application will not know the connection has dropped.
When a UniVerse process goes into a critical code section, it will not
immediately respond to the interrupt of the SIGHUP. The typical example is
when it initiates acquisition of the group lock in preparation for a
read/write. When that operation completes, it returns to responding to
signals, and then it sees the SIGHUP, and would clean up and exit.
The most frequent occurence of a "stuck" process is when it initiates an
I/O operation and it encounters a group lock. At this point it will not
respond to a "kill -15" because it is postponing that response. Do NOT use
"kill -9 *pid*" to kill the stuck process. It may have other resources
locked and you will only propagate other problems. With enough perseverance
(a topic for another post...) you can determine what resource the stuck
process is awaiting and clear it (if it is erroneous), and the stuck
process will complete its task and continue.
There is a special condition in signal handling for the uvsh process (that
is not in the replication uvrw processes) that allows you to cleanly kill
the stuck process. If the process sees enough "critical" signals, it
assumes something bad is happening, and will exit the critical code
section, clean up, and exit anyway. If you instead issue "kill -6 *pid*"
six times, the process should report that it is not there on the sixth
command entry. In the early days, C compilers would occasionally generate
bad code, and you would see programs abort with an illegal operation,
signal 4. I just chose a signal 6 for the critical signal to distinguish it
from the occasional signal 4 aborts I would see in the late 1980s.
That is the logic behind hupcl. The clocal directs to dialup connections.
It is for Carrier Local. If the connection is local, ignore a dropped
carrier signal. You want to pay attention, so -clocal says to recognize the
disconnect if the carrier drops.
Set them using the shell command "stty hupcl -clocal". Note that EXECUTE
"SH -c 'stty...'" only sets the parameters of the subshell of the UniVerse
session and not your current session. The command should be in the login
script. The UniVerse PTERM command equivalent for hupcl is -NOHANG. So, in
the UV account, in the UV.LOGIN, you could place a "PTERM -NOHANG" to get
the same effect.
I was once giving a UniVerse Performance and Tuning seminar that I
developed; fielded a question about these disconnected sessions, and gave
the above response. Many had tried to solve the problem and failed. They
later sent me a note saying they had not seen the problem again after
making the changes.
The caveat to setting hupcl and -clocal is that one customer said it
affected some of their sessions. It was long ago, and I do not remember the
details, but I think it was something with their network switches and some
instability with them. However, I never got a full response from them.
Be well and prosper,
Original Message:
Sent: 5/25/2022 8:31:00 AM
From: Lappies Labuschagne
Subject: Dead user Sessions
Please advise
With the ongoing power failures, we are experiencing that users are being
kicked off from their pc's or terminals , But the user session is still open
on the server. In other words, when doing a LISTU it still shows these
users as being logged on. Is there a config/timeout-setting that can logoff
these dead sessions automatically after e.g. 1 minute?
Regards
Lappies Labuschagne
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus