Question Timeout in a linux environment

grinder

Member
Hello there,

we have many users who don't disconnect when leaving the office. Applications runs on Red Hat Enterprise Linux Server release 6.3 (Santiago)
Is there any startup-parameter to set the timeout for idle users? Or any other idea how to handle this issue?

Thank you in advance.
 

TomBascom

Curmudgeon
The version of RH is interesting but the version of Progress is much more interesting. Given the ancient release of RH I'm going to guess that you are ashamed to admit to running Progress v9.

No, there is no startup parameter to timeout idle users.

Nor is there any simple, easy and reliable way to identify "idle" users. While it may seem like something that is obvious and simple, every allegedly simple method that you might think you find will turn out to have flaws and hidden complexities.

Truly "idle" users are not causing any problems and don't really need to be "handled". Just leave them alone. Attempts to somehow "handle" idle users tend to cause harm. For instance - many naive attempts to handle such situations lead to sending a "kill -9" to the user's process. This may seem to work well in development but will eventually lead to crashing your production database.

If you are going to go ahead and try to do something anyway here is a partial list of things to check before you decide that a user's session is "idle":

Is the session an interactive session or a batch session?
Is the session using the -p startup procedure that you expect? Is it connected to the correct database?
Has there been any input from the keyboard?
Is the session waiting for something like input from a file or a socket?
Is any output being written (to the screen or to any files or sockets)?
Is the session blocked waiting for a database resource? (Such as a record lock?)
Does the session have an active transaction?
Is the session connected to multiple databases?
Is the session doing anything at a db level? (Reading records?)
Is the session accumulating CPU time? Disk IO operations? Network packets?

If you are going to terminate a session that you have decided is idle:

First use the "proshut -C disconnect" option.
Check the .lg file and make sure that any "transaction backout" is allowed to complete.
If "proutil disconnect" does not work then use "kill -1".

Do not use "kill -9" unless you are prepared to crash your db.

Also -- make certain that you have good backups and that your after-image files are in good shape.
 
Last edited:

Rob Fitzpatrick

ProgressTalk.com Sponsor
Mostly off-topic:

This isn't helpful for grinder but there is actually a parameter of sorts on Windows only called ClientTimeOut. I say "of sorts" because it isn't implemented as a client or broker startup parameter but rather as a registry setting. I just became aware of it recently and I've never used it.

More details:
Progress KB - How to use the ClientTimeOut Startup Parameter.

Back on topic:

I understand the motivation to do this; one of our applications has an optional feature to disconnect a subset of users before the nightly batch run. But please heed Tom's advice.

My own view is that features like this are a response to problem symptoms rather than the underlying cause.

Example:
A user goes into an "update" screen in the UI; maybe to update something, maybe just as a shortcut for querying something they don't intend to update. (It might even be a particularly badly-written query screen!) Unbeknownst to them, they are in a transaction and hold exclusive locks on one or more records. Then they go for a coffee, go to a meeting, leave work early, etc. Now you have a bad situation brewing. First, they have started a transaction that isn't going to end anytime soon and that, combined with other users' activity will cause BI growth, given sufficient time. Second, they might be holding a record lock that some other client will later try to acquire, causing it to block (depending on how it's written).

Ultimately this causes database problems and business disruption and after a post-mortem, someone decides that the thing we need to do to eliminate these unwanted locks is to kick out "idle users", either at the end of the business day or after some period of idleness. It sounds simple and straightforward at first blush but as Tom points out there are a lot of subtleties to the problem. And you'll probably also boot some users who are causing no harm.

The root cause is technical debt; the way the application is designed and the fact that seemingly ordinary user behaviours (at least from the user's perspective) can cause big problems. The best long-term solution is to pay the debt: refactor those programs with optimistic locking, tighter transaction scope, transactions that don't span UI interactions, and code that won't block for half an hour when it encounters an unexpected lock.

I understand that that isn't a quick or trivial undertaking, particularly with a large code base. In the interim, it's important to monitor the application databases to understand which clients are causing the problems and which programs they are running at the time, as they need to be fixed, and which programs are the victims as they may need to be refactored too. Start with the most frequent offenders and fix as you discover them.
 

RealHeavyDude

Well-Known Member
I've not come up with a solution of disconnecting users from the database after 30 minutes of inactivity - but I am forced to come up with one around the end of the year. For what it is worth, our application has been penetration tested by external consultants who even didn't understand the different behavior of an application that runs in the browser and a GUI client.

Nevertheless, they had 2 findings, one of which was that idle users are not disconnected after 30 minutes of inactivity which poses a security threat as our application is handling sensitive data. They told our management that for our application the session lifetime is not handled correctly on the web server ...
You cannot argue with senior risk management - so I will have to find a creative solution on how to detect an idle session. I didn't think about it much yet - it is sufficient when I go crazy when I have to.

Bottom line, while it does not make any sense and does not increase security ( like enforcing users to change passwords on a regular basis ), still the external consulting industrial complex requires such things to be implemented in order to get a sign-off.
 

TomBascom

Curmudgeon
Auditors... the last refuge ;)

If it were me I would go back to them and ask for an actionable definition of "idle". I would then ask for clarifications for each of the various bullet points above. I'd be especially anxious for them to provide their expert advice on making the very difficult risk trade-off and development investment evaluations with regards to making the application unavailable due to overly enthusiastic session termination.

You might wonder if that would "piss them off" or something but I kind of doubt it. I think they are more likely to be thrilled that you are taking their "findings" seriously and excited to be working with an engaged business partner. If you do it properly the process could take several years and 3 or 4 changes of audit teams. It will also keep them distracted since they will have an active "finding" for your application and won't need to invent another until this one is closed.

Did I say "distracted"? Oops, I mean "focused"...
 
Top