[ale] too many logins

Todor Fassl fassl.tod at gmail.com
Tue Nov 11 18:04:50 EST 2014


Yeah, I guess I was looking for a miracle. A combination of all these 
things will probably do the trick. Really, just disabling the list of 
recent logins will be good enough. I don't think anybody will object to 
that either. It didn't occur to me to do that because all of the 
machines in the department are identical and the profs would object if 
they had to type in their user id each time. But I think I can disable 
it just for the lab machines easily enough.

I should probably make it difficult for an end user to reboot these 
machines. I haven't done that because when they lock up the machine with 
a bad piece of code, I don't want them comeing to me. I'm not sure how 
effective that will be anyway. I have nagios configured to send a wake 
on LAN packet if someone turns a machine off. One day,  nagios kept 
telling me that a machine was down. I went down there and someone had 
unplugged it and set the power strip on the table next to the machine. I 
guess they really wanted that machine off and to stay off.

In a way, I thought it was kind of funny. The student must have been 
turning the machine off only to have it keep coming back on all by itself.


On 11/11/2014 01:15 PM, Jim Kinney wrote:
> Teach people how to use screen/tmux for their long running console jobs.
> Teach them nohup for when they get autologged out (see below)
>
> +1 disable user name display as mentioned earlier
> +1 disable non-root power control as earlier
>
> #set  a5  min timeout policyfor  bash shell
> TMOUT=300
> readonly  TMOUT
> export  TMOUT
>
>
> set up the above in /etc/profile and users can't change it locally.
>
> Setup a cluster aware job control process like gridengine and kill off
> local console access for all but one head node.
>
> On Tue, Nov 11, 2014 at 1:54 PM, Boris Borisov <bugyatl at gmail.com
> <mailto:bugyatl at gmail.com>> wrote:
>
>     Disable shutdown-reboot for non root users maybe !
>
>
>     On Tuesday, November 11, 2014, Todor Fassl <fassl.tod at gmail.com
>     <mailto:fassl.tod at gmail.com>> wrote:
>
>         The biggest problem is that the login screen gets crowded with
>         the names of other users who have logged in recently. Students
>         don't see the box to enter a different user ID so they reboot
>         the machine which kills off any  matlab or sage jobs somebody
>         else might have started. After a reboot, the login screen has
>         maybe one or two names on it. There must be some fairly complex
>         algorithm for determining who gets on that list because I cannot
>         see a pattern.
>
>
>
>         On 11/11/2014 12:15 PM, Ed Cashin wrote:
>
>             I was reading kind of fast, but I'm not sure you pointed out any
>             specific ill effects.  I'd expect the kernel to page to disk
>             the pages
>             in RAM associated with the unused sessions.  So once all the
>             matlab
>             state (etc.) is on the swap partition, there'd be little
>             cost associated
>             with a stale login as long as you have plenty of swap
>             space.  Maybe
>             everything is already fine now?
>
>             On Tue, Nov 11, 2014 at 11:55 AM, Todor Fassl
>             <fassl.tod at gmail.com
>             <mailto:fassl.tod at gmail.com>> wrote:
>
>                  Suggestions?
>
>
>
>
>                  On 11/11/2014 10:47 AM, JD wrote:
>
>                      Is there a question?
>
>                      On 11/11/2014 11:32 AM, Todor Fassl wrote:
>
>                          I have a problem in a lab I am responsible for.
>             The lab has
>                          7 debian stable
>                          machines. Students log in to check mail, browse
>             the web,
>                          etc. But they
>                          frequently walk away without logging out. Soon
>             enough, the
>                          screen saver comes on
>                          and the next person sits down and logs in as
>             another user.
>                          Often, the first
>                          person comes back hours late or the next day
>             and logs in a
>                          second time. Some of
>                          these machines have the same user logged in 5
>             or 6 times.
>
>                          The problem is that some of these students
>             start matlab,
>                          sage, or magma jobs
>                          before they walk away from the workstation.
>             Those are
>                          legitimate jobs and should
>                          not be killed.  In fact, sometimes students ssh
>             to these
>                          machines and run
>                          computations. It's kind of a bad idea but I'd
>             rather not
>                          tell them not to do
>                          that. Otherwise, I'd just have the machines reboot
>                          themselves every  night.
>
>                          We used to use a tool called timeoutd but it
>             seems to have
>                          been removed from the
>                          debian stable and ubuntu archives.  I was never
>             able to get
>                          it to work right
>                          anyway. Students would complain that their jobs
>             had been
>                          killed or that they
>                          were logged out while they were typing away. At
>             the same
>                          time, I could see that
>                          other users were still logged in after
>             days/weeks of
>                          inactivity. I am not sure
>                          the problem really was with timeoutd because
>             finger often
>                          gave me weird
>                          results.I'm not sure linux was giving timeoutd
>             correct data
>                          to work with.
>
>                      ___________________________________________________
>                      Ale mailing list
>             Ale at ale.org <mailto:Ale at ale.org>
>             http://mail.ale.org/mailman/____listinfo/ale
>             <http://mail.ale.org/mailman/__listinfo/ale>
>                      <http://mail.ale.org/mailman/__listinfo/ale
>             <http://mail.ale.org/mailman/listinfo/ale>>
>                      See JOBS, ANNOUNCE and SCHOOLS lists at
>             http://mail.ale.org/mailman/____listinfo
>             <http://mail.ale.org/mailman/__listinfo>
>                      <http://mail.ale.org/mailman/__listinfo
>             <http://mail.ale.org/mailman/listinfo>>
>
>                  ___________________________________________________
>                  Ale mailing list
>             Ale at ale.org <mailto:Ale at ale.org>
>             http://mail.ale.org/mailman/____listinfo/ale
>             <http://mail.ale.org/mailman/__listinfo/ale>
>                  <http://mail.ale.org/mailman/__listinfo/ale
>             <http://mail.ale.org/mailman/listinfo/ale>>
>                  See JOBS, ANNOUNCE and SCHOOLS lists at
>             http://mail.ale.org/mailman/____listinfo
>             <http://mail.ale.org/mailman/__listinfo>
>                  <http://mail.ale.org/mailman/__listinfo
>             <http://mail.ale.org/mailman/listinfo>>
>
>
>
>
>             --
>                 Ed Cashin <ecashin at noserose.net
>             <mailto:ecashin at noserose.net>>
>
>
>             _________________________________________________
>             Ale mailing list
>             Ale at ale.org
>             http://mail.ale.org/mailman/__listinfo/ale
>             <http://mail.ale.org/mailman/listinfo/ale>
>             See JOBS, ANNOUNCE and SCHOOLS lists at
>             http://mail.ale.org/mailman/__listinfo
>             <http://mail.ale.org/mailman/listinfo>
>
>         _________________________________________________
>         Ale mailing list
>         Ale at ale.org
>         http://mail.ale.org/mailman/__listinfo/ale
>         <http://mail.ale.org/mailman/listinfo/ale>
>         See JOBS, ANNOUNCE and SCHOOLS lists at
>         http://mail.ale.org/mailman/__listinfo
>         <http://mail.ale.org/mailman/listinfo>
>
>
>
>     --
>     Sent from Gmail Mobile
>
>     _______________________________________________
>     Ale mailing list
>     Ale at ale.org <mailto:Ale at ale.org>
>     http://mail.ale.org/mailman/listinfo/ale
>     See JOBS, ANNOUNCE and SCHOOLS lists at
>     http://mail.ale.org/mailman/listinfo
>
>
>
>
> --
> --
> James P. Kinney III
> ////
> ////Every time you stop a school, you will have to build a jail. What
> you gain at one end you lose at the other. It's like feeding a dog on
> his own tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> ////
> http://heretothereideas.blogspot.com/
> ////
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>


More information about the Ale mailing list