Idle Users

Fri Jun 18 07:33:44 PDT 2004

Thanks to all who responded.  I tested the clicking x to see if that was
what was happening.  I logged in as me and clicked x.  It logged me out
just fine.  That was just one of the ideas that came to mind because we
have a fair number of new users and I thought maybe that was what was
happening.  Apparently not!  My other 2 ideas are that either users are
opening a session, going into something else and then forget that they
have the DejaWin session already open and open another one OR the other
cause may be that the DejaWin sessions freeze up from time to time.
I've had it happen where I'm in the middle of something and the screen
freezes for a few seconds then disappears.  Then, you have to log back
in.  However, if you try to go back into the record you were in, it says
it's being updated.  If I go in and look at who is logged in, I can see
where that person is logged in twice.  If I kill the process that's been
idle, it frees up the record.  I thought that idleout wasn't working
because we already had idletime=120 and it obviously wasn't doing
anything.  However, we didn't have it set up to run automatically.  We
have now set it to do that.  We'll see how it goes!

Vicky Prigg
Laparkan Trading Ltd.
2929 NW 73rd St.
Miami, FL 33147

-----Original Message-----
From: filepro-list-bounces at lists.celestial.com
[mailto:filepro-list-bounces at lists.celestial.com] On Behalf Of
filepro-list-request at lists.celestial.com
Sent: Friday, June 18, 2004 3:15 AM
To: filepro-list at lists.celestial.com
Subject: Filepro-list Digest, Vol 5, Issue 78

Send Filepro-list mailing list submissions to
	filepro-list at lists.celestial.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.celestial.com/mailman/listinfo/filepro-list
or, via email, send a message with subject or body 'help' to
	filepro-list-request at lists.celestial.com

You can reach the person managing the list at
	filepro-list-owner at lists.celestial.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Filepro-list digest..."

Today's Topics:

   1. Re: Idle Users (Bill Vermillion)
   2. Re: Idle Users (Fairlight)

----------------------------------------------------------------------

Message: 1
Date: Thu, 17 Jun 2004 20:16:35 -0400
From: Bill Vermillion <fp at wjv.com>
Subject: Re: Idle Users
To: Fairlight <fairlite at fairlite.com>
Cc: filepro-list at lists.celestial.com
Message-ID: <20040618001635.GC22708 at wjv.com>
Content-Type: text/plain; charset=us-ascii

On Thu, Jun 17, 2004 at 05:27:31PM -0400, Fairlight thus spoke:
> On Thu, Jun 17, 2004 at 05:13:04PM -0400, Kenneth Brody, the prominent
pundit,
> witicized:
> > 
> > You're assuming that closing the window by clicking the "x" causes
the
> > telnet session to be ended, and a SIGHUP to be sent.

> If it doesn't, there's something wrong with either the emulator or the
> ssh/telnet/whatever daemon--or both.  

See my other message with the TA where the default telnet timeout
is 2 hours.

-- 
Bill Vermillion - bv @ wjv . com

------------------------------

Message: 2
Date: Thu, 17 Jun 2004 21:00:48 -0400
From: Fairlight <fairlite at fairlite.com>
Subject: Re: Idle Users
To: filePro Mailing List <filepro-list at seaslug.org>
Message-ID: <20040617210048.A2394 at iglou.com>
Content-Type: text/plain; charset=us-ascii

At Thu, Jun 17, 2004 at 05:11:42PM -0700 or thereabouts, 
suspect Bob Rasmussen was observed uttering:
> 
> Because lots of function keys are needed by many users, we never even
> consider Alt-F4 as synonymous with Quit. We capture it, and allow the
user
> to attach a keymap to it.

Gotcha.  I thought it was a binding but had never tested in my own
coding.
I thought I'd run into something that captured it though.  I guess it's
a
WM default if the app doesn't re-bind, then.

> You misunderstand. It's not that telnetd or sshd would trap the HUP.
They
> pass it along or even generate it in the case where the connection
goes
> down. The problem is when some shell script in the process tree has
> trapped the HUP, or when the runtime ignores it (not the case with
fP).

Understood.

If someone is trapping HUP, I'm of the school of thought that says they
live with the consequences of their actions.  I've trapped it before,
but
never in a context that would be harmful.  Just long enough to
gracefully
finish an atomic logical operation and then exit.

I really don't think planning for that far down the chain is the job of
the
emulator or its developers.  That's a case of the server-side
environment,
IMHO.  So long as the client-side is graceful and does things properly,
I
think it's up to the server admins/users to configure their environment
and
applications properly.

> Thanks for your comments on 'screen', too.

My pleasure.  It's really invaluable.  I've used it since before it ever
got switched to the FSF.  It used to be hosted at orst.edu.  :)  It was
great for those wonderfully...uhm, stable (*cough*) 1200/2400 baud modem
connections we had back in the day.  Saved many a headache and much code
loss.

One additional note to that is that you might also check out 'multiuser
on'
and the access control functionality in screen.  I've used it (today,
even)
to bring people in and let them attach to my session concurrently for
training, collaboration, or just demonstration.  And you can nicely set
it
so that a list of users can access your sessions, but they can have only
certain access to certain multiplexes.

Assume I have screen multiplexed with three "windows" (for lack of a
better word).  One is 'fairlite' local to my linux box, one is my shell
account, and one is root on my linux box.  I can force it so that 'bob'
can read/write to the first, read-only on the second, and not even get
at the root one at all.  It's pretty robust.  About my only complaint is
that -both- sides must (apparently) trigger the screen-switching
bindings.
If I'm on and someone attaches, they don't necessarily start on the same
screen I'm currently on, and when I switch, they also have to switch.
It
can be used independantly by multiple parties, and logging off the main
session doesn't nuke the other users off of that session as it would in
DoubleVision--that's the upside.  But in a training situation, if you
deal with multiple windows, I wish there was a way to force the switch
to
all connected users -from- the user who owns the session.  It's a bit of
a
trade-off.  However, besides offering what you wanted, it pretty much
acts
like a DoubleVision or ttysnoop substitute.

Hey Jay, if you're reading--I've been over the man page like 30 times.
Is
there actually a way to do what I want with it with the binding in
multiuser mode?  Something I've missed?  *hopeful look*

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications
today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html

------------------------------

_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
http://mailman.celestial.com/mailman/listinfo/filepro-list

End of Filepro-list Digest, Vol 5, Issue 78
*******************************************