<html><head></head><body><div>On Wed, 2016-04-20 at 16:20 -0500, Todor Fassl wrote:</div><blockquote type="cite"><pre><snip></pre></blockquote><div><br></div><blockquote type="cite"><pre> What we really need is a distro that is 6 months
behind everyone else but does updates every 6 months.
<snip>
</pre></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><blockquote type="cite"><pre>
On 04/20/2016 02:32 PM, DJ-Pfulio wrote:
<blockquote type="cite">
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:
<blockquote type="cite">
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:
<blockquote type="cite">
Anyone using screen, tmux or nohup?
On Wed, 2016-04-20 at 11:52 -0500, Todor Fassl wrote:
<blockquote type="cite">
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
<a href="mailto:Ale@ale.org">Ale@ale.org</a>
<a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
_______________________________________________
Ale mailing list
<a href="mailto:Ale@ale.org">Ale@ale.org</a>
<a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</blockquote>
</blockquote>
</blockquote>
_______________________________________________
Ale mailing list
<a href="mailto:Ale@ale.org">Ale@ale.org</a>
<a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</blockquote>
</pre></blockquote><div><span><pre>--
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/
</pre></span></div></body></html>