(794) Usernum xyz terminated abnormally. - looking for thu

Posted by reiner klawzinske on 19-Sep-2017 00:41


Hello all.


I’m in charge for a bunch of progress databases 10.2B – running ProAlpha ERP – and I see in all of them sometimes this pair of error messages:


[2017/06/19@22:11:38.143+0200] P-14520     T-4172 I SRV   50: (794)   Usernum 317 terminated abnormally.

[2017/06/19@22:11:38.144+0200] P-14520     T-4172 I SRV   50: (739)   Logout usernum 317, userid LVS, on DPC-LVS.


There is mainly one kbase entry, which reflects this problem and searching here the forum again gives only a small number of entries.

So first of all I really wonder if this happens so seldom that no one has do deal with it.


anyway, are there any general thumb rules or hints, you could share with me?

We have already set the TCPKeepalive Pram in the Opsys down to 1 hour, is this enough?

comes any misconfig to you mind, whey o read this? Of course my colleagues from networking are disagreeing any possible problems from their side,

and I would be happy for a starting point for futher investigations.


Best regards,

Reiner Klawzinske
ERP dept.

All Replies

Posted by George Potemkin on 19-Sep-2017 09:08

> SRV   50: (794)   Usernum 317 terminated abnormally.

Session was killed: kill -9

Posted by reiner klawzinske on 19-Sep-2017 09:19


thanks for that quick answer. unfortunately the Client is running in a GUI session on Win 7.

there are different users having this problem and it seems they are even used to it. I called the different times, and the reply was like "oh, my session broke, so I started it again..."  - "does this hapen often?" - "not too much, but once a week..." - which makes me really worrying :-)

Posted by ChUIMonster on 19-Sep-2017 09:42

I would set TCP keepalive much lower.  5 minutes is probably more than long enough.  It is not an "inactivity" timer -- it is a "broken connection" detector.  The default of 2+ hours might have been reasonable in 1980.  It is not reasonable today.

Posted by George Potemkin on 19-Sep-2017 09:43

> unfortunately the Client is running in a GUI session on Win 7.

You can try to find the footprints of the session's crush on user's machine.

Posted by ChUIMonster on 19-Sep-2017 09:45

If users are deciding to kill their own sessions you probably ought to be looking into why they are doing that.   In a lot of cases it is because there are performance issues that are giving them the impression that their session is "hung".  If you address the underlying performance problem you will likely reduce the frequency of users taking matters into their own hands.

Posted by cjbrandt on 19-Sep-2017 12:22

What service pack of 10.2B are you using.  SP08 has some additional parameters for client server connections.

Posted by reiner klawzinske on 20-Sep-2017 00:32

OpenEdge Release 10.2B08 as of Tue Nov 12 19:06:41 EST 2013

Sorry I could have started with the necessary Details.

Could you point me a bit to the mentioned paramters please?


Posted by reiner klawzinske on 20-Sep-2017 06:48

Hello Tom (and all)

unfortunately there is one "special" user with a "special" clinet session, which definitely doesn't kill his own session - and even more unfortunately, this is the really one, in which I'm interested.

we have a very old interface program, which passes Information from / to the stock management System.

this "interface" is a dedicated pseudo user, which connects from a PC to the ProAlpha (Progress) database and runs one program.

this is basically an endless loop which looks into a special Directory, reads information, converts it and passes the result into another directory, then pauses 1 second, and again.

we start this session and then just leave it running. when it hangs we look onto this PC and see the sessin has ended with the mentioned message in the database log.

I cannot change the programming for additional logging (far too complex fo me), but I can swear, nobody cancels it for example by using the Task Manager.

this program uses to be runing without Problems between half a day and 2 or 3 weeks.

there is no pattern in time or weekday or any else when it stops working.

I started to look for this Special user in the database log, and found then other (rea) users having the same problem.

but htis "autmated" user Shows, that there is no interference from "outside", it just hangs.

Posted by George Potemkin on 20-Sep-2017 06:55

Reiner, all these sessions are dying without transactions, aren't they? Do you see the transaction rollback messages in db log? If not then I would persistently monitor the read activity per users to check if the sessions are too "aggressive" before their death.

Posted by George Potemkin on 20-Sep-2017 07:18

Is it possible that the sessions are connected to more than one database and they are inactive in one of these databases for a long time? Check ClientTimeOut parameter in registry on the machines running databases.

Article: How to use the ClientTimeOut Startup Parameter.


Posted by ChUIMonster on 20-Sep-2017 07:39

So this special "user" a process running on a Windows PC?

How, exactly, does it get started?

You have to be *really* careful with this kind of stuff on Windows.  If you are just logging in and starting it or if you are starting it from "scheduled tasks" then it will be killed anytime the same userid logs off from that PC.  Even if that particular session had nothing to do with launching the special process.

To run such a process safely you need to either run it as a service (I like a utility called NSSM to control that) or you can setup a scheduled task so long as the userid for the task is a "functional id", that is a userid that NEVER logs in (you also need to make sure the password doesn't expire).

Posted by reiner klawzinske on 20-Sep-2017 07:45

pause 86400.

thanks for the replies, will take time to rethink all :-)

Posted by reiner klawzinske on 20-Sep-2017 08:23

it is a normal user session on a dedicated PC.

I or an admin colleague login as user_x to  the PC, we start the Application  you go into a "normal" menu System and start a certain GUI program.

this is an endless Loop, which Looks into a Directory, finds a new line (or not) for/from  the Stock Management System, processes it, waits a second and starts again the loop.

after having started this prog we Close the rdp session from that PC by cling on the X in the upper right Corner and don't touch that PC anymore, until the shipment depratment complain,s there are no papers comping out of their System :-)

over night or over the weekend it is verly like that there is nothing to do for hours.  then it runs only the Loop, pauses a second, and again.

I cannot Change the program to be a background  process, becuase it's written by the Software vendor and far too commplicated for me.

Posted by George Potemkin on 21-Sep-2017 01:17

> it's written by the Software vendor

For the test purposes you can run a session that imitates the behavior of your special user. Check if the session will be crashed if it's running for a long time.

Posted by jakuosma on 21-Sep-2017 04:14

This is not Progress related, its related how RDP server are configured.

1. Printing ->  If  you use sesion printers to printing, printing stop if you close rdp session, configure printer on rdp server and use this printer for printing

2. Are RDP server sessions timeout are configured


Jari Kuosmanen

Digia PLC

Posted by cjbrandt on 21-Sep-2017 07:37

Enabling client logging may help determine why the session stops / crashes / bombs ...

This thread is closed