I think what James was commenting on was the situation that Gadi 
mentioned where someone might opt to NOT kill some left-over processes 
for some terminals.

I consider it a bug that the processes don't die on their own, but 
pinning down exactly where the bug is can be very difficult.  It's not 
like the old days of remote communication via modem, where, if you lose 
carrier detect, the session dies.

In our world, when the client mysteriously disappears, there's nothing 
to notice that.  sshd on the server should eventually detect it, but 
many times, the user can reboot the terminal and attempt a login, before 
sshd figures out that the session has gone away.

There are some configuration options for sshd that you can tune to 
better detect lost connection.

In the man-page for sshd_config, take a look at:

   ClientAliveCountMax
   ClientAliveInterval

Those 2 parameters can be adjusted to try to detect a lost connection. 
But, the default setting for ClientAliveInterval is '0', which disables it.

Optimally, I think you'd want to time how long it takes to boot a thin 
client, and set the 2 parameters to something that would be just shorter 
than a boot time.

Setting it too small can result in false positives killing sessions 
prematurely.  For instance, someone may reboot a core switch, which 
could take long enough to make sshd think the session is dead.

In the end, I think the script that Gadi and Blinny came up with is 
necessary.  So... great job guys.

Jim McQuillan
[EMAIL PROTECTED]



Michael Blinn wrote:
>>> If you try it, please give feedback.
>>>
>>> The script should be placed in:
>>>
>>> /opt/ltsp/i386/usr/lib/ldm/rc.d/S15userLoginCheck
>>>
>>> and then, reroll the image.
>>>
>>> NOTE:  Older versions of ldm, may have the rc.d directory
>>> in:  /opt/ltsp/i386/usr/share/ldm/rc.d/
>>>     
>> When you logout ALL processes you spawned as login are supposed to die. 
>> Using 
>> that they don't as a feature is going to make blood someday.
> 
> Supposed to, yes. However, I've found with Hardy Heron and LTSP5 that 
> many times stale processes _are_ left over, especially when a client 
> does not exit gracefully. I am in the unfortunate position of having to 
> use some very old machines as LTSP clients - though I had thought this 
> was a main tenet of the project, apparently technology marches on - some 
> of which are PI 233Mhz boxes. These, though functional, sometimes lock 
> up. After a hard reboot, the server still has many processes laying 
> around that prevent the user from logging back in. I needed a way to 
> clean out old sessions and start a new one, and this script accomplishes 
> exactly that.
> 
> Like Gadi said, the eventual plan is to wrap this under an lts.conf 
> variable so it can be enabled/disabled as your setup requires. I can 
> envision kiosk setups or public labs wherein this functionality would 
> not be desirable.
> 
> -Michael
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _____________________________________________________________________
> Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help,   try #ltsp channel on irc.freenode.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to