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