idle timeout
Calvin Wong
Calvin
Randy Styka
>
> sample config for the sco unix of telnet session idle timeout ??
>
> Calvin
Hi! In the user's .profile, if they are using ksh, you
can set the variable TMOUT to the number of minutes of
inactivity to allow. A similar variable is in the csh.
But these settings only work for users at a shell prompt,
not in applications.
There are programs that can log off idle users in other
situations. A common one is called "idleout". A limitation
of these is that they use keyboard activity only as a
criteria for logging off users. In other words, a user
running a cpu bound job with no keyboard activity could
still be logged out.
So our company wrote (and sells ;-) a package called
LOGMON that monitors the cpu usage for each user, and
their child processes. That way we can be sure the user
really is idle. You can vary the inactivity time by user,
time of day, etc. For details, send a message to
log...@computron.com or visit www.logmon.com.
Good luck!
+-----------------------------------------------------------------+
| Computronics Randy Styka, ra...@computron.com |
| 4N165 Wood Dale Road Phone: 630/941-7767 |
| Addison, Illinois 60101 USA Fax: 630/941-7714 |
+-----------------------------------------------------------------+
Brian K. White
> Calvin Wong wrote:
> >
> > sample config for the sco unix of telnet session idle timeout ??
> >
> > Calvin
>
> Hi! In the user's .profile, if they are using ksh, you
> can set the variable TMOUT to the number of minutes of
> inactivity to allow. A similar variable is in the csh.
> But these settings only work for users at a shell prompt,
> not in applications.
>
> There are programs that can log off idle users in other
> situations. A common one is called "idleout". A limitation
> of these is that they use keyboard activity only as a
> criteria for logging off users. In other words, a user
> running a cpu bound job with no keyboard activity could
> still be logged out.
>
> So our company wrote (and sells ;-) a package called
> LOGMON that monitors the cpu usage for each user, and
> their child processes. That way we can be sure the user
> really is idle. You can vary the inactivity time by user,
> time of day, etc. For details, send a message to
> log...@computron.com or visit www.logmon.com.
>
> Good luck!
So what does that do about my users who's desktops go away on
power-save, or who's flaky net connections break, thus leaving their
process running without a terminal, spinning like mad consuming 100%
cpu for 4 days until enough of these things accumulate that they call
me because the server is too slow?
I have already managed to eliminate the dreaded X button, but there
are still the above examples that are outside my control. (sure the
power-save is controllable but desktops keep being replaced or
re-formatted or new ones added, users play with their settings, users
allow programs to play with their settings... it's cotrollable the way
cats are. that is, in theory it should be possible, but...)
We need a telnet/ssh/xyz-term server daemon that monitors the client
the way IRC servers do. and/or an idleout program that tries to be
nicer than "kill -9 you all" ideally with a config file that tells it
what signals to try in what order and and with what timeout and retry
values, and ideally with the ability to set different actions for
different programs.
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
John DuBois
Brian K. White <br...@aljex.com> wrote:
>So what does that do about my users who's desktops go away on
>power-save, or who's flaky net connections break, thus leaving their
>process running without a terminal, spinning like mad consuming 100%
>cpu for 4 days until enough of these things accumulate that they call
>me because the server is too slow?
You can probably get that under control by using 'ulimit -t' (see the ksh man
page) in the appropriate places. I went through a year's worth of process
accounting records and found the processes that consumed the most CPU time that
were started from a shell login by a regular user and that weren't clearly
processes that had gone into spin loops, and then set a soft CPU time limit
that is high enough that given this history, it's unlikely that any process
will ever be killed for legitimate CPU consumption. It turned out that 300
seconds was high enough; the users here mostly run lightweight apps. I left
the hard CPU time limit unlimited, so I can remove the time limit from my X
sessions for the sake of Netscape and such. This means that a process that
goes into a spin loop dies after 5 minutes.
>and/or an idleout program that tries to be
>nicer than "kill -9 you all" ideally with a config file that tells it
>what signals to try in what order and and with what timeout and retry
>values, and ideally with the ability to set different actions for
>different programs.
Try ftp://deepthought.armory.com/pub/admin/nidleout
Doesn't do everything you want, but is nicer about killing and far more
configurable than idleout.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Tony Lawrence
> We need a telnet/ssh/xyz-term server daemon that monitors the client
> the way IRC servers do. and/or an idleout program that tries to be
> nicer than "kill -9 you all" ideally with a config file that tells it
> what signals to try in what order and and with what timeout and retry
> values, and ideally with the ability to set different actions for
> different programs.
Well, John Dubois's nidleout is a BIG improvement in that direction. I
also wrote some experimental stuff ( http://pcunix.com/Unix/piddle.html
) that exhibits my usual crappy coding but that might have the germ of
an idea for someone with more talent who wants to write something better,
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Tom Parsons
| <semi-advertisement snipped >
|
| So what does that do about my users who's desktops go away on
| power-save, or who's flaky net connections break, thus leaving their
| process running without a terminal, spinning like mad consuming 100%
| cpu for 4 days until enough of these things accumulate that they call
| me because the server is too slow?
|
| I have already managed to eliminate the dreaded X button, but there
| are still the above examples that are outside my control. (sure the
| power-save is controllable but desktops keep being replaced or
| re-formatted or new ones added, users play with their settings, users
| allow programs to play with their settings... it's cotrollable the way
| cats are. that is, in theory it should be possible, but...)
|
| We need a telnet/ssh/xyz-term server daemon that monitors the client
| the way IRC servers do. and/or an idleout program that tries to be
| nicer than "kill -9 you all" ideally with a config file that tells it
| what signals to try in what order and and with what timeout and retry
| values, and ideally with the ability to set different actions for
| different programs.
Instead of trying to reinvent well known protocols, why not look at
the source of the problem which is probably the application. I don't
remember you mentioning particular processes but this was/is a very
common occurrence with some versions of BBx, particularily the older
versions. Those versions of BBx never understood how to kill the
child processes.
If it is these older BBx processes, then no amount of fiddling with
tcp/ip protocols is going to help because, although less common, it
would occasionally occur on systems with dumb terminals and no networking.
The workaround was fairly simple, just run a daily script that searches
for those processes and kills them. And, yes, they were killable.
There is a logic failure in most kill scripts in that they often just
kill the parent and leave it up to the parent to clean up the children.
A better kill logic is to construct each process tree and kill it
from the bottom up. John DuBois's marvelous proctree script will build
the tree, as well as provide all sorts of other interesting information.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Brian K. White
filePro, any version from current down.
they do respond to kill -HUP and records are released lockfiles
updated, etc...
sometimes they are just sitting at a menu, which has no files or
records to lock, but the cpu is still a problem.
dumb terminals can still lock up or be shut off or suffer bad
connections, but a serial terminal has a nice simple hardware
solution. You wire the terminal up right, and configure the serial
port to watch dcd, and if the terminal goes away, the processes
recieve hup like god intended :)
I know tcp can't have something quite like that, because it's the very
nature of the connection that it is not constant but in the form of
packets which are expected to sometimes hit blockages and congestion
etc. So the only thing I can think of that would provide something
similar is for the server daemon (which started the first login and
from there can work out the whole process tree)
to do something that amounts to pinging the client and if it fails to
respond within some given (and configurable) schedule, pretend it is a
serial line that just lost dcd.
To the other replies: Thanks I'll check out those souped-up idleout
and other scripts.
Randy Styka
>
> Randy Styka <ra...@computron.com> wrote in message news:<3C87E2...@computron.com>...
> > Calvin Wong wrote:
> > >
> > > sample config for the sco unix of telnet session idle timeout ??
> > >
> > > Calvin
>
> power-save, or who's flaky net connections break, thus leaving their
> process running without a terminal, spinning like mad consuming 100%
> cpu for 4 days until enough of these things accumulate that they call
> me because the server is too slow?
>
> I have already managed to eliminate the dreaded X button, but there
> are still the above examples that are outside my control. (sure the
> power-save is controllable but desktops keep being replaced or
> re-formatted or new ones added, users play with their settings, users
> allow programs to play with their settings... it's cotrollable the way
> cats are. that is, in theory it should be possible, but...)
>
> We need a telnet/ssh/xyz-term server daemon that monitors the client
> the way IRC servers do. and/or an idleout program that tries to be
> nicer than "kill -9 you all" ideally with a config file that tells it
> what signals to try in what order and and with what timeout and retry
> values, and ideally with the ability to set different actions for
> different programs.
>
signals are used, in what order, and lets you vary it by
application. And it kills from the lowest process up rather
than just killing the parent. As Tom Parsons said, this can
make a difference in many systems. So I know we have dealt with
both of these.
None of this addresses the "looping process" issue. Tony
Lawrence's ulimit idea is a good one. We've never thought
about it that way. I will have to say that this issue seems
to be much more of a problem on SCO (OSR5) systems than on
other Unix platforms. I have no idea why. Our Logmon works
to gracefully log off idle users, not looping users. But we
get calls from users asking for this capability (killing cpu
hogs) on a regular basis. But for some reason these users tend
to be on SCO OSR5 and not our AIX, HPUX, Solaris, Tru64
users, etc. It makes me wonder if there isn't something in
the kernel that makes these systems more likely to have this
problem when sessions aren't closed properly.
The only thing we have observed is that if a customer has a
".profile" that includes a "trap" that ignores signal
SIGHUP (-1) they have the problem all the time. When the
kernel tries to kill the process the ".profile", or sometimes
the applications themselves, are ignoring the SIGHUP and they
will go into a cpu loop. So I always suggest a check for this.
But in many cases, no such trap is found and yet the looping
occurs on an improperly closed session. Oh, well, maybe we'll
look at the "ulimit" workaround. Always something to think
about...
--