Not all patches require rebooting the kernel. Most do not. On 04/30/2016 10:56 AM, William Warren wrote: > ALL systems need patching so obsessing about uptime is insecurity on its > face. It doe not matter if it is windows or linux or anything else. > > > On 4/30/2016 11:33 AM, Valeri Galtsev wrote: >> On Sat, April 30, 2016 8:54 am, William Warren wrote: >>> uptime=insecurity. >> This sounds like MS Windows admin's statement. Are there any Unix admins >> still left around who remember systems with kernel that doesn't need >> [security] patching for few years? And libc that does not need security >> patches often. I almost said glibc, but on those Unixes it was libc; >> glibc, however, wasn't getting security patches too often some long time >> ago as well. Because these are only kernel and libc/glibc that do require >> reboot (no splice or similar for me on servers, thank you). >> >> It sounds to me like the system you are talking about, and us, sysadmins >> administering it, is pretty much in MS Widows ballpark already. Right? >> >> Sorry about my rant. I still consider not well debugged code not well >> debugged code... >> >> Valeri >> >>> Patches must be kept up these days or your uptime >>> won't matter when your server gets compromised. >>> >>> >>> On 4/22/2016 4:33 AM, Rob Townley wrote: >>>> tune2fs against a LVM (albeit formatted with ext4) is not the same as >>>> tune2fs against ext4. >>>> >>>> Could this possibly be a machine where uptime has outlived its >>>> usefulness? >>>> >>>> On Thu, Apr 21, 2016 at 10:02 PM, Chris Murphy >>>> <lists at colorremedies.com> >>>> wrote: >>>> >>>>> On Tue, Apr 19, 2016 at 10:51 AM, Matt Garman >>>>> <matthew.garman at gmail.com> >>>>> wrote: >>>>> >>>>> >>>>>> # rpm -qf `which tune2fs` >>>>>> e2fsprogs-1.41.12-18.el6.x86_64 >>>>> That's in the CentOS 6.4 repo, I don't see a newer one through 6.7 but >>>>> I didn't do a thorough check, just with google site: filter. >>>>> >>>>> >>>>>> # cat /etc/redhat-release >>>>>> CentOS release 6.5 (Final) >>>>>> # uname -a >>>>>> Linux lnxutil8 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 >>>>>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>> And that's a centosplus kernel in the 6.6 repo; while the regular >>>>> kernel for 6.7 is currently kernel-2.6.32-573.22.1.el6.src.rpm. So I'm >>>>> going to guess you'd have this problem even if you weren't using the >>>>> centosplus kernel. >>>>> >>>>> I suggest you do a yum upgrade anyway, 6.7 is current, clean it up, >>>>> test it, and then while chances are it's still a problem, then it's >>>>> probably a legit bug worth filing. In the meantime you'll have to >>>>> upgrade your e2fsprogs yourself. >>>>> >>>>> >>>>>> I did a little web searching on this, most of the hits were for much >>>>>> older systems, where (for example) the e2fsprogs only supported up to >>>>>> ext3, but the user had an ext4 filesystem. Obviously that's not the >>>>>> case here. In other words, the filesystem was created with the >>>>>> mkfs.ext4 binary from the same e2fsprogs package as the tune2fs >>>>>> binary >>>>>> I'm trying to use. >>>>>> >>>>>> Anyone ever seen anything like this? >>>>> Well the date of the kernel doesn't tell the whole story, so you need >>>>> a secret decoder ring to figure out what's been backported into this >>>>> distro kernels. There's far far less backporting happening in user >>>>> space tools. So it's not difficult for them to get stale when the >>>>> kernel is providing new features. But I'd say the kernel has newer >>>>> features than the progs supports and the progs are too far behind. >>>>> >>>>> And yes, this happens on the XFS list and the Btrfs list too where >>>>> people are using old progs with new kernels and it can be a problem. >>>>> Sometimes new progs and old kernels are a problem too but that's less >>>>> common. >>>>> >>>>> >>>>> -- >>>>> Chris Murphy >>>>> _______________________________________________ >>>>> CentOS mailing list >>>>> CentOS at centos.org >>>>> https://lists.centos.org/mailman/listinfo/centos >>>>> >>>> _______________________________________________ >>>> CentOS mailing list >>>> CentOS at centos.org >>>> https://lists.centos.org/mailman/listinfo/centos >>> _______________________________________________ >>> CentOS mailing list >>> CentOS at centos.org >>> https://lists.centos.org/mailman/listinfo/centos >>> >> >> ++++++++++++++++++++++++++++++++++++++++ >> Valeri Galtsev >> Sr System Administrator >> Department of Astronomy and Astrophysics >> Kavli Institute for Cosmological Physics >> University of Chicago >> Phone: 773-702-4247 >> ++++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos