Quote:
Originally posted by champion
Ok, good question...
Well there are two possibilities here....
Maybe "pulling the plug" will drop dtr on a terminal or something that will result in the shell getting a HUP signal. In this case, the shell will exit and it will perform the .logout or the trap commands that will remove the lock file. The user, at this point is no longer "logged in", the lock file is gone and there is no problem.
Or maybe "pulling the plug" will not result in a HUP being sent to the login shell. So it will continue to sit there. The user is still "logged in", the lock file continues to exist. And so the user cannot login again.
That is the whole point, right? No concurrent logins? If this bothers you, then why do it?
Users should not be "pulling the plug" as a logout mechanism. I would pose the same question to them: It this bothers you, then why do it?
There are some counter-measures that can help some here. Most shells have a timeout mechanism. For example, in ksh you can set TMOUT to a number of seconds. When that number of seconds passes without a command being typed, the shell will exit. As it does, it will execute any commands set to "trap" on signal zero. A built-in shell timeout mechanism will work for any style of connection. And the user can customize the timeout period to suit his needs.
If they connected on a directly attached terminal, they can turn it back on and continue with the session. You should be able to arrange for the port to notice DTR from the terminal dropping when a terminal is turned off. This would send a HUP to the login shell.
If they are connecting via modem, you have a real security problem. You need to insure that when the modem notices that carrier dropped, a HUP is sent to the login shell. If this is not done, the next person to use that modem will inherit the first persons session.
If they are connecting via tcp/ip, you can configure keepalives to break the connection and send the shell a HUP in the process. But whatever you do will affect all tcp connections. Tcp keepalives are controversial so you may want to think about this first.