UNIX for Advanced & Expert Users

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.

No matter what you do, you are going to have folks who do not logout correctly and may leave a session out there.

If you use something like introcomp.co.uk - restrict login you would also have to have something to kill off users who are idle for a certain amount of time. Setting up each .profile would also be a hassle (especially if with the linked script ) if you wanted to change how many logins were allowed. Setting up a link from all home directories to a common .profile might be a way around that ( it matters if your home directories are NFS mounts or not).

Found that this works just as well in /etc/profile - of course, you might want to change the logic and allow root and other special accounts to get around the limit set.

Also note that the script does not stop Control-C break outs which could allow folks to have more than one session. A cron script to look for specific user and more than one terminal association could kill off second process (again, more work to figure out which is which).

Without 3rd party software which would make this easier, your options are limited and a headache you might not want to do.

If someone pulls the power cable, you simply clear all lock files during the reboot process. There are no sessions after a power failure so it is appropriate to clear all the session locks.