[ale] Lab Workstation Mystery

Jim Kinney jim.kinney at gmail.com
Wed Apr 20 17:42:39 EDT 2016


On Wed, 2016-04-20 at 16:20 -0500, Todor Fassl wrote:
> <snip>
>  What we really need is a distro that is 6 months 
> behind everyone  else but does updates every 6 months.
> 
> <snip>
> 

Let me introduce you to Fedora. 23 is latest-n-greatest but 22 is still
getting bug and security patches. New version every 6 months. 1 year
old version dies about a month after the newest version is released.
New libs, mostly cutting edge but not bleeding edge. Gets new
technology with each new release. As the admin running a one-back
setup, you get 6 months to hammer on the next version before you
deploy. By testing public alpha and beta releases for next drop, you
get the jump on the process. Usually by beta2 it's pretty much ready to
go.
I ran the HPC stack on Fedora at work for 2 years. Currently CentOS7 as
the libs they want now are standard. Will move back to Fedora as soon
as I can get some code built for CentOS/RHEL happy with newer libs in
Fedora.
> 
> 
> 
> 
> 
> On 04/20/2016 02:32 PM, DJ-Pfulio wrote:
> 
> > 
> > Stuff like this is a reason why running non-LTS isn't recommended, unless
> > absolutely required due to new hardware that hasn't been backported yet. There
> > are other reasons NOT to touch non-LTS releases.
> > 
> > "New" != Better
> > 
> > BTW, Ubuntu 16.04 LTS release is TOMORROW.  I'll be waiting a few months before
> > deployment (maybe 2 more yrs), but will start playing with the server version
> > Friday. I don't touch desktop releases from Canonical anymore.  All the hassles
> > just aren't worth the effort.
> > 
> > IMHO, systemd still needs a few more years of painful use by others before it
> > will be ready enough for my needs.  14.04 barely has any systemd, but some
> > power-related settings are controlled by it.
> > 
> > Of course, I'm not everyone else. Many thanks to folks chasing "new" - I did my
> > time in the 1990s doing that.
> > 
> > On 04/20/2016 02:00 PM, Todor Fassl wrote:
> > 
> > > 
> > > I verified that if you log in and then just log back out immediately, those same
> > > 4 processes remain running, systemd, sd-pam, ibus-daemon, and ibus-dconf. I
> > > don't have a plain ubuntu 15.10 system handy but I'll bet it does the same
> > > thing. Anybody have a machine like that? Login at the console, log out, ssh to
> > > the machine as another user, and see if there are any processes still running
> > > for the user who just logged out.
> > > 
> > > I tried switchng a machine to use gdm instead of lightdm, no joy.  I think I'm
> > > logging in via gnome. I can try unity too.
> > > 
> > > I think it's a systemd issue. In fact, I think it's a "feature" of systemd. It
> > > messes up autofs though.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On 04/20/2016 12:31 PM, Jim Kinney wrote:
> > > 
> > > > 
> > > > Anyone using screen, tmux or nohup?
> > > > On Wed, 2016-04-20 at 11:52 -0500, Todor Fassl wrote:
> > > > 
> > > > > 
> > > > > I posted about this problem a couple of weeks ago and still have not
> > > > > figured it out. The problem is that on a group of machines running
> > > > > ubuntu 15.10, after a period of time, mounting home directories via
> > > > > NFS
> > > > > hangs. Attempting to mount or unmount home directories via NFS
> > > > > simply
> > > > > hangs. Eventually, the root filesystem getsremounted read-only and
> > > > > the
> > > > > machine becomes unusable even as a local user. One thing I've
> > > > > discovered
> > > > > since my first post about this is that when end-users log out, some
> > > > > processes do not get killed off. The automounter can't umount the
> > > > > home
> > > > > directory because the user still has some processes running.
> > > > > Eventually,
> > > > > the machine has several home directories mounted via NFS for users
> > > > > who
> > > > > are no longer logged in. I am thinking that what is happening is
> > > > > that
> > > > > eventually this causes NFS to get wedged which in turn leads to the
> > > > > kernel freaking out. Or something. Here is an example of the output
> > > > > from
> > > > > listing the processes for a user who has logged out:
> > > > > 
> > > > > # ps -u enduser1
> > > > >        PID TTY          TIME CMD
> > > > >     101794 ?        00:00:00 systemd
> > > > >     101795 ?        00:00:00 (sd-pam)
> > > > >     103049 ?        00:00:00 ibus-daemon
> > > > >     103057 ?        00:00:00 ibus-dconf
> > > > > 
> > > > > 
> > > > > So frequently, even though a user has logged out days ago, the
> > > > > systemd
> > > > > and ibus-deamon might still be running. I am thinking after enough
> > > > > time,
> > > > > these things mess up the nfsv4 kernel module which eventually messes
> > > > > up
> > > > > the kernel itself.
> > > > > 
> > > > > But why would logging out *not* killoff all of an end-user's
> > > > > processes?
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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> > > > > 

> > > > 

> > > 
> > > 
> > > 

> > 
> > 
> > _______________________________________________
> > 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
> > 
> > 
> > 

> 
> 
> 

-- 
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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160420/c3c8f1a9/attachment.html>


More information about the Ale mailing list