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

Hello!

There are a number of different options, but it will depend on your environment - UniVerse or UniData? Windows or Unix?
Other environmental variables include the type of connection (telnet/SSH, unripe, etc.), and what you have for security requirements (idle timeout, etc.).

In our environment - UniVerse on AIX - there is a file called unirpcservices under the unishared directory. In that file, you can configure a number of parameters for each type of unirpc connection, including the timeout value. I think this is specific to Unix environments, though. More info on the unirpcservices file can be found in the UV Admin Guide.

Another option is to use the AUTOLOGOUT command in your LOGIN paragraphs. HELP AUTOLOGOUT will give you more info.

Realize that some of these options may/will not work if the user session has an active record lock. We've noticed on our system that if a session is holding a lock, it may not always automatically clean up. We usually end up having to go in and release the lock, and then the cleanup process takes care of the rest.

Hope this helps.

Brian

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

If you are running on Windows the technote on the telnet keep alive may help you as well.

Abstract

UniData / UniVerse had no way to tell for certain if a telnet client had terminated a TCP/IP session. The result being that a client process can appear to remain "alive" after a normal logout from UniData or UniVerse.

Solution

The Keep Alive functionality was added to allow an administrator to configure the UniData / UniVerse telnet service to better handle this situation. It is a specification of tcp/ip. The concept is to test connections to see if they are alive when they are idle. If there is no response from the client after the defined parameters have been met, the socket is closed. This option allows the server to detect situations where the client application has failed but no close message can be sent by the client PC, for example when the client PC has crashed or the network link has been lost. With Keep Alive, the server sends a probe message to each client application at a set time interval. If the server does not receive a reply to the probe message, the server closes down the session cleanly. The default frequency of the probe is set to 2 hours, however to ensure processes are cleaned up more frequently a lower setting of say 10 minutes can be chosen.

The Keep Alive parameters are documented on chapter 3 of "Administering UniData on Windows and UNIX Platforms" guide and chapter 17 of "Administering UniVerse on Windows and UNIX Platforms" guide.

In the "Extensible Administration Tool", click "Admin Tasks", then select "Network Services" and then click "UDTelnet" for UniData and click "Telnet" for UniVerse.
The Keep Alive parameters appear on the right side of "Update UniData / UniVerse telnet settings" tab. To update "Keep Alive" settings, you need to select "Keep Alive" checkbox first.

Keep Alive - enable/disable keep alive feature.
Keep Alive Interval - the time in milliseconds, to separate keep alive retransmissions until a response is received.
Keep Alive Time - the time in milliseconds, to specify how often TCP attempts to verify that an idle connection is still valid by sending a keep alive packet.
Max. Data Retransmissions - specifies the number of times TCP retransmits an individual data segment before aborting the connection.

Click "Save" button to save the change. Stopping and starting the UniData telnet service alone has no effect, a system reboot is required.

Note: On the Windows platform, you can verify the UniData / UniVerse Telnet keep alive settings in the system registry path "HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters". For some Windows 10 PC, a "shut Down" doesn't fully shut down Windows, it hibernates the kernel, saving its state so it can boot faster. If you're experiencing computer problems and need to reset that state, you'll need to restart your PC instead.


------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------

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

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,

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

You could also use the TANDEM command in FEED mode to take over control of the still running but disconnected process and find where it was at. Tedious if more than a few sessions to deal with but very useful if you need to complete a transaction or something like that. Run it in UV account as the superuser.
------------------------------------------------------------------------------- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600)

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

Could you please specify if you are using Windows, or Unix/Linux underneath?

Tandem was never implemented for the Windows version, IIRC

------------------------------
Will Johnson
Systems Analyst
Rocket Forum Shared Account
------------------------------

Could you please specify if you are using Windows, or Unix/Linux underneath?

Tandem was never implemented for the Windows version, IIRC

------------------------------
Will Johnson
Systems Analyst
Rocket Forum Shared Account
------------------------------

Good day



Thank you Gentleman for all the advice.



The Server is running Windows Server 2019 STD and Universe 12.1.1.1017

I will investigate further using Jonathan Smith’s suggestions.



Thank you.