On Wednesday 28 September 2005 20:18, Max wrote:

Ignacio Vazquez-Abrams wrote:

...

Wow. Blaming the OS vendor for an ISV's issues.

That whizzing sound you hear is my eyes rolling over and over again, really quickly.

Yeah, wow...I've been using Red Hat products since 7.3. I've ran 8, 9, and all the Fedora Core distros. Now I run CentOS, and we use RHEL 3 at my work. I've never had any distro, even the Fedora "Testbed's" just stop working, unless I caused the issue myself from playing.

Hmmm, interesting. Now, understand that I use Linux daily, and that I have no plans of switching around. However, reading the article I get the following summary: 1.) Paying Customer had to use particular software components, including a particular version of RHEL; 2.) Paying Customer had intermittent lockups of the machine that were difficult to reproduce; 3.) Paying Customer got tired of Red Hat's 'WORKSFORME' bug resolution (that's the typical bugzilla tag when such an irreproducible problem occurs); 4.) Paying Customer quit paying and switched to Windows, which worked better for them (meaning, it didn't crash).

Now, just exactly what part of this is untrue or would require a Microsoft payoff? I personally have seen instances of Red Hat's WORKSFORME attitude; one example is the version of tftp being shipped with RHEL3 and 4, 0.39. 0.40 has been out for a while, and it fixes a nasty bug in the tftp file translation (remapping) feature/misfeature (which I have had to use before on certain releases of Cisco's 7960 IP telephone). Red Hat has a bug in bugzilla on this issue for RHEL3 that predates U4, yet the bug won't be addressed until U7! And even then the two-line patch has to be backported; can't let the customer see a higher version number! (Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143536 ) Follow the thread; with such a simple bug taking so long, what kind of mess are bigger bugs in?

And there are several kernel bugs that are like this, with strange lockups and such that are either ignored (NOTABUG or WONTFIX resolution) or the reporter is told to file 'upstream'. See the list at https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Red+Hat+Enterprise+... for yourself, particularly bug ID's 157170 (Closed: Wontfix), 162653 (Closed: Wontfix because it's a CentOS kernel) and163373 (Closed: Wontfix megaRAID-old). Yeah, I can just see a bug filed in LKML by a Red Hat customer getting priority attention from Linus and Co. I can see that about as good as I can see myself walking on the moon tomorrow.

Let me put it this way: if I were paying $1,200 per server per year for RHEL support, I would not tolerate the WORKSFORME attitude either; I would expect and demand that Red Hat send someone out to my site and diagnose my problem for those costs (and if they wouldn't do it, I would find a vendor that would, for that price, which is exactly what this particular customer did). Since I am not paying Red Hat for support at this point, I obviously cannot have that attitude with bugs I find that are clearly Red Hat bugs; but I certainly can understand this guy's attitude. We shouldn't just automatically dismiss such a problem as being a troll. We should look intelligently and logically at the problem.

And no matter what ISV's software is running, the OS should not LOCK UP! Sounds like a RHEL kernel issue to me.

So, Jim Perrin, I think a HAHAHAHAHA is entirely inappropriate. This guy had a real problem, and Red Hat couldn't fix it. Meaning CentOS still has the problem on that same hardware under the same conditions, since CentOS is as close to upstream RHEL as is possible under the trademark guidelines.

We're not told what 'diagnostic' Red Hat recommended be run on the box, but I know that if I were in the same situation I would ask Red Hat to come to my site and pull that data themselves. That's what I pay for for support, in my opinion. If I buy 'turnkey' I expect field circus to make it turnkey. (Of course, old-timers will recognize the DEC jab there, and the whole idea of turnkey is a Bad Idea in my opinion, but that is the world we're in. See http://nemesis.lonestar.org/stories/stages.html for a very humorous tale from an old-timer in the computer business. This guy, Frank Durda IV, wrote much of the I/O processor code for the Tandy 6000 Xenix computer of the mid-80's, so he is quite a character.)

Further, as to 'automatic' updates, I totally agree with Mr. Horton in the article. Automatic updates should Just Work and should not break the whole system (things like, oh, I don't know, caching-nameserver hosing files (caching-nameserver is STILL INSTALLED BY DEFAULT EVEN WITH bind-server installed, which is a recipe for this sort of problem), an httpd update that fails to properly restart httpd after update, the kernel quits working with your hardware, you know, minor inconveniences that can only cost thousands of dollars of downtime, nothing major). Everyone has seen some of the updates come down in broken states; search the archives of nahant-list or taroon-list for lots of those. I personally have turned off automatic updating at several sites for these reasons and because of the poor track record of automatic updates.

And, furthermore, I thought the whole idea of the RHEL platform was ABI stability. If SAP thinks, as an ISV, that they need to recertify every update then something is bad wrong, and it's not necessarily at SAP. I personally hypothesize that SAP perhaps got burned one too many times by a poor update and now blanket recertifies for every update to make sure their customers keep running. "Poor stupid ISV trying to serve their customers...they should Get With the Program!" Of course, Windows has this problem, too, but it's typically limited to Service Packs. Yuck, just typing that phrase turns my stomach, thinking about what Win2k3 SP1 does to certain many dozens of programs...

Sorry for the rant, but it is ridiculous to automatically dismiss a real-world problem. Note that the same Mr. Horton is still using Linux for web services and such, and likes and supports it in that role; it's just the SAP server he had to transition to Windows due to a lowly business concern. Nope, the business bottom line should never interfere with technological zealotry!

Oh, quick quiz: what happens to a CentOS box when you reboot after running out of disk space on the / filesystem? You get a graphical login just fine, but then you can't login (you login, and it returns you to a login). Not hard to fix, but very mysterious to the newbie.

On Thursday 29 September 2005 11:21, Les Mikesell wrote:

Why is it news worth publishing that some piece of hardware somewhere crashes in a way that no one else can reproduce?

Slow news day.

But, more to the point, it's not the fact that it broke that bothers me. It's the attitude that it is Always Foolish to switch from Linux to Windows and that Anyone and Everyone that does so has been paid off by MS. That's all. Linux is not perfect, and is not the solution for all IT problems.

...

Sorry for the rant, but it is ridiculous to automatically dismiss a real-world problem.

Problems happen all the time. Why is this one newsworthy? If someone made such a big deal out of every Windows BSOD

Slashdot. 'Nuff said.

there wouldn't be room to publish anything else? The problem could almost certainly have been fixed as well by replacing the problematic hardware (even if the problem is in the Linux driver it will be fixed by using something different).

Not having specifics we cannot state that authoritatively. In any case, if Win2k3 works fine on the same hardware, is it a hardware problem?

Would it still be a big news item: "PC crashes,owner buys replacement!"?

Depends on the cause of the crash and how slow a news day it is. On really slow news days you learn all kinds of odd things. Like a gerbil that was born with two heads or something.

On Thu, 2005-09-29 at 15:02, Mike McCarty wrote:

...

Problems happen all the time. Why is this one newsworthy? If someone made such a big deal out of every Windows BSOD there wouldn't be room to publish anything else? The problem could almost certainly have been fixed as well by replacing the problematic hardware (even if the problem is in the Linux driver it will be fixed by using something different). Would it still be a big news item: "PC crashes,owner buys replacement!"?

The point is fourfold:

(1) RHEL is PAID TO CARE

Some PC's crash. I'm sure everyone at RHEL feels bad about that. Others run for years running the same software.

(2) MS software ran, and RHEL did not, so

MS has some cozy arrangements with hardware vendors and may very well include code to work around specific bugs in specific hardware that is not disclosed to the public. In fact I'd pretty much bet on it. Is it the hardware vendor's fault or RHEL's that the same workarounds haven't been disclosed in open source drivers? Or is it the customer's fault for not picking more dependable hardware?

(3) the customer left for greener pastures, and (4) RHEL can expect more of the same...

Except from people whose hardware doesn't crash, which is most of them. The problem may very well be something in the linux device drivers but the point is that it isn't reproducible which is why it shouldn't be news. I've been through that myself with a box that would crash under load about every other week but nothing I tried would cause it to happen predictably. I moved the same software to a different box and went on with life. And they probably could have done the same.

Les Mikesell wrote:

On Thu, 2005-09-29 at 15:02, Mike McCarty wrote:

...

...

Problems happen all the time. Why is this one newsworthy? If someone made such a big deal out of every Windows BSOD there wouldn't be room to publish anything else? The problem could almost certainly have been fixed as well by replacing the problematic hardware (even if the problem is in the Linux driver it will be fixed by using something different). Would it still be a big news item: "PC crashes,owner buys replacement!"?

The point is fourfold:

(1) RHEL is PAID TO CARE

Some PC's crash. I'm sure everyone at RHEL feels bad about that. Others run for years running the same software.

But RH was accepting money and being paid to do something about it.

...

(2) MS software ran, and RHEL did not, so

MS has some cozy arrangements with hardware vendors and may very well include code to work around specific bugs in specific hardware that is not disclosed to the public. In fact I'd pretty much bet

I dunno whether what you say be true, but certainly I do *know* for a fact that vendors write drivers for WinXXX and put information into those drivers on how to initialize hardware, for which *no* specs are available, about defects or otherwise. So... certainly RH is operating at a disadvantage with respect to MS.

on it. Is it the hardware vendor's fault or RHEL's that the same workarounds haven't been disclosed in open source drivers? Or is it the customer's fault for not picking more dependable hardware?

You do miss the point, here. It matters not who's "fault" it may be. It does matter that a customer was lost, for whatever reason.

...

(3) the customer left for greener pastures, and (4) RHEL can expect more of the same...

Except from people whose hardware doesn't crash, which is most of them. The problem may very well be something in the linux device drivers but the point is that it isn't reproducible which is why it shouldn't be news. I've been through that myself with

Umm, you are arguing against something I didn't claim. I claim that it is of interest to me, because it may affect the future of a product which I use. Do you disagree with that?

a box that would crash under load about every other week but nothing I tried would cause it to happen predictably. I moved the same software to a different box and went on with life. And they probably could have done the same.

Umm, I dunno about that. I *am* aware of how the organization treats some customers who pay for support, and I do know that it has in past driven other customers away. I have seen the same attitude in other suppliers cause better products to die, while inferior products flourish, due to the difference in support. I'd prefer that Linux flourish and not die just because MS is willing to do more of what is necessary to make life easier on customers than some other organization which supports Linux is willing to do.

Mike

On Thu, 29 Sep 2005 16:58:42 -0500 Mike McCarty mike.mccarty@sbcglobal.net wrote:

I'd prefer that Linux flourish and not die just because MS is willing to do more of what is necessary to make life easier on customers than some other organization which supports Linux is willing to do.

Its apples and oranges. MS can afford to do whatever their customers want since Windows, Office, and all their other software is *theirs* (or licensed for their use).

Given enough financial incentive (a big enough customer base requesting feature x) MS can do whatever they want with their code to sell feature x to more customers.

Red Hat doesn't *own* Linux. While they can aid in development, and help point it in a certain direction, there are numerous things about Linux they have no control over and never will.

So... certainly RH is operating at a disadvantage with respect to MS.

....

But RH was accepting money and being paid to do something about it.

So long as they provide good service for a certain (high) % of their customers, they will do fine. A certain % will walk away unsatisfied. I think Red Hat does great given their challenges.

Ryan wrote:

On Thu, 29 Sep 2005 16:58:42 -0500 Mike McCarty mike.mccarty@sbcglobal.net wrote:

...

I'd prefer that Linux flourish and not die just because MS is willing to do more of what is necessary to make life easier on customers than some other organization which supports Linux is willing to do.

Its apples and oranges. MS can afford to do whatever their customers want since Windows, Office, and all their other software is *theirs* (or licensed for their use).

When was the last time that MS fixed a but that you reported? I doubt anyone can even report a bug to MS. A few years back there was a problem with the wininet api docs on the MSDN website. I reported a problem via their web page and a few days later I got an email back saying that I must be mistaken because nothing can go wrong with MSDN. The pages were still broken and after a few more emails, they actually checked the pages and saw that they were broken. The problem then went away without any acknowledgment.

I still can't get Word 2003 do display bitmaps. This is a long standing bug and in my book, a showstopper. MS don't give a shit because they already got their money. I am not the one paying so I can't vote with my feet. Sure, I can use Linux instead but then we are paying for MS products we don't use.

If something with linux is wrong, anyone can fix it. Linus, RedHat, me, anyone I pay to do it for me. If linux was blue screening (sounds like windows to me) then they should do a crashdump, find the bug and fix it. Still cheaper and easier than windows.

Good luck solving a windows problem by looking at a stop screen.

I'd also like to know how windows autoupdate is better than any redhat up2date style tool. Do SAP say "You can put any MS shit on here that you like but if you run Linux you need to have a proper test procedure"? I don't think so.

John.

Given enough financial incentive (a big enough customer base requesting feature x) MS can do whatever they want with their code to sell feature x to more customers.

Red Hat doesn't *own* Linux. While they can aid in development, and help point it in a certain direction, there are numerous things about Linux they have no control over and never will.

...

So... certainly RH is operating at a disadvantage with respect to MS.

....

...

But RH was accepting money and being paid to do something about it.

So long as they provide good service for a certain (high) % of their customers, they will do fine. A certain % will walk away unsatisfied. I think Red Hat does great given their challenges.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

[ I've temporarily subscribed my Yahoo address to post this single comment, and then I'm going to unsubscribe it so I can't post again. ]

I think everyone here has started to miss the point, and the commentary I've seen would not stand up well to professional criticism. These studies, articles and other commentary, reflections, etc... may have an agenda, agreed. But you must _be_technical_ and focus on the commentary in the article. That's how you explain things.

You don't explain things by having meta-discussions on some Microsoft payoff, what Red Hat failed to do, does and doesn't control in Linux, etc... The end-user discussed in this article clearly had its _own_issues_, largely based on how the gentleman who came into support the solution.

Yes, Red Hat is responsible for their Service Level Agreements (SLAs). And yes, Red Hat _does_ control a _lot_ of major, official packages in Linux itself (even if most people don't realize that). Red Hat's support and services expect you to give them proper information, work with them on issues, detail specifics so they can work with ISVs whose products are certified against specific configurations, etc... Apparently, from what I've read, the end-user didn't even bother to recognize their involvement and just had a "work dammit" attitude.

Fact: The local support personnel came in _after_ the Linux solution was chosen

Fact: The local support was experienced in AIX, _not_ Linux

Fact: Red Hat requested diagnostics be run by the end-user, and they were _not_ run by the end user (again, more "just work dammit attitude")

Professional Experience: This seems to be a clear example of the end-user lacking any wish to give Red Hat a "benchmark" which they could work with, so they could reproduce the setup and, correspondingly, the issue

Fact: The comparison of automated updates of Red Hat Network versus Microsoft System Update Service (SUS) are laughable.

Professional Experience: In maintaining both large Red Hat and Microsoft networks, SUS is _not_ a viable update/CM solution. I typically feed SUS from Altiris and other patch management solutions which do a far better job of tracking Windows-ISV patch issues, and even Windows-MSApp compatibility issues.

E.g., When SQL Slammer hit in early 2003, Microsoft divisions that were feeding SUS from Altiris did _not_ go down because Altiris identified the 2 patches to SQL Server that _uninstalled_ the SQL Server patch (from 4 months earlier) that would have prevented them from being suseptible to SQL Slammer.

Fact: The generalities and lack of specifics are really the undoing of the technical merits of this article.

Let's use specific quotes from the article itself -- especially the middle sections -- to get to the "heart of the matter."

'Red Hat Australia did its best to support Cress Electronics with the issue until it decided to move to Windows, says Red Hat Australia general manager Max McLaren. We asked the customer to do a diagnostic test and the customer never responded, so it was impossible for us to address the issue," Mr McLaren says.'

You have to send Red Hat information to debug and find the root cause. They will. They always do. Apparently the customer "just wanted it to work."

My personal guess: This AIX guy didn't know how to run any diagnostics in Linux, and was generally unfamilar with the Linux platform.

2) The bogus TCO/update non-sense, totally BS

'... Mr Horton also found the total cost of ownership included soft costs such as the hard work required to keep Linux up and running. Software updates had to be manually installed to ensure SAP certification. "With the manual process of patching, we were spending about two days a month ensuring that and testing. A lot of people call it a soft cost, because you've got IT people anyway but they shouldn't be spending all day maintaining the system," Mr Horton says.

Alright, now we get to more BS. If it's a matter of comparing updates, how is that different than in Windows?

In fact, Red Hat does a damn fine job of backporting to guarantee 100% compatibility. They excel at this better than not only any Linux distribution, but any UNIX I've seen.

Heck, Windows has more inter-dependent patches than _any_ UNIX. Need I bring up SQL Slammer again? Microsoft's post-SQL Slammer changes have helped, but they are _not_ as "piecemeal" as UNIX/Linux.

'Red Hat Australia's Mr McLaren says there is no risk of losing vendor certification if an organisation enables auto-patching on Red Hat Enterprise Linux. "Every patch goes through our engineering and quality testing, which involves certification by the vendor. It absolutely doesn't invalidate the support from the software vendor," he says.'

People wonder why RHEL "costs so much." It's the certifications -- that time, effort and energy to re-certify every major Update against Oracle, SAP, DB2, etc... That costs redundant time and money, and one of the reasons Red Hat wanted to move to supporting 2-3 products released every 18 months, instead of 6-7 products released every 6 months.

Red Hat can and does offer a better level of certication of ISV software with SLAs than Microsoft. Microsoft _only_ offers SLAs for Enterprise customer ISVs. They rely on Tier-1 OEMs (HP, IBM, Dell, etc...) for anyone smaller than Enterprise (or Education/major Government).

'Mr Horton disagrees: "It might be fine for things like security patches, which don't impact SAP certification rules but with some patches you still actually have to check the release levels and then check against the SAP site. Otherwise SAP might ask you to roll back to the previous version before they will support it."'

Again, how is this _any_different_ than Windows?!?!?! I honestly can't believe they compared RHN/Update to SUS?!?!?! God knows Microsoft itself deploys Altiris internally for damn good reasons (which is why I do as well for Windows)!

'Crest Electronics is trialling Microsoft's Windows Server Update Service, which allows automatic patching for the operating system and other Microsoft software on servers and desktop machines across a corporate network.'

Again, how is this _any_different_ than Red Hat's update management system "across a network"?!?!?! I still can't believe they are comparing it to SUS.

'Its benefits are one of the key reasons why Mr Horton stands by his decision to switch from Linux to Windows.'

It's benefits are based on the fact that Mr. Horton is _wholly _ignorant_ of not only Linux's capabilities, but those that come with RHEL -- including updates "across a corporate network."

File this one on "Linux loses due to incompetent local support resources." No need to have meta-discussions on anything else -- the comparison of RHN/Update to SUS is laughable.

I won't post on this matter again. There is no need, and it's not because I don't want to be blamed for this off-topic/meta-discussion thread (which I hope people are smart enough to note these happen _regardless_ of whether or not I am subscribed ;-).

Mike McCarty wrote:

Bryan J. Smith wrote:

...

[ I've temporarily subscribed my Yahoo address to post this single comment, and then I'm going to unsubscribe it so I can't post again. ]

Welcome back, Bryan! As you can see, verbose, off-topic, flame-ridden, ill-informed, nearly immortal threads are alive and well, here.

Oh, and topic-drift. Did I mention topic-drift?

:-)

Mike

Bryan J. Smith wrote:

File this one on "Linux loses due to incompetent local support resources." No need to have meta-discussions on anything else -- the comparison of RHN/Update to SUS is laughable.

Nice response. Yeah, it sounds like Mr. Horton was just looking for an excuse to switch to windows and didn't make any real effort to address the problem.

I've been using RH in production environments since around 95, and have had very good success. I've never had a problem with automatic updates. Just rebooted a RHEL database machine that's been working 24/7 for the last 390 days (kernel upgrade). And that's not exceptional.

Maurice

Mike McCarty wrote:

<snip>

...

a box that would crash under load about every other week but nothing I tried would cause it to happen predictably. I moved the same software to a different box and went on with life. And they probably could have done the same.

Umm, I dunno about that. I *am* aware of how the organization treats some customers who pay for support, and I do know that it has in past driven other customers away. I have seen the same attitude in other suppliers cause better products to die, while inferior products flourish, due to the difference in support. I'd prefer that Linux flourish and not die just because MS is willing to do more of what is necessary to make life easier on customers than some other organization which supports Linux is willing to do.

Mike

Hear, hear, hear ....

On Thu, 2005-09-29 at 16:27 +0000, Ingimar Robertsson wrote:

On Thu, Sep 29, 2005 at 11:04:52AM -0400, Lamar Owen wrote:

...

Red Hat has a bug in bugzilla on this issue for RHEL3 that predates U4, yet the bug won't be addressed until U7! And even then the two-line patch has to be backported; can't let the customer see a higher version number!

That is interesting. I thought this was their policy until yesterday when there was an update on wget which bumped the wget version from 1.9.1 to 1.10.1. And this update in fact broke a couple of my scripts which used the "--http-passwd" option which in 1.10.1 is "--http-password" with no backward compatibility to the older "--http-passwd" option.

In my case this wasn't serious, just short review of the man page, fix the scripts and rerun. But had this be some commercial software from a big vendor, things could have broken badly.

This article looks like a slow news day story but has valid points but the one thing I can't understand is how Microsoft automatic updates can be less error prone than RedHat's. I have seen patches and of course service packs create so much havoc in Windows that I personally don't think they still have had any updates on their system and are therefore still happy with it. ;-) This is something that I've never seen (until the above mentioned wget issue) with RedHat Enterprise.

---- A lousy Ford dealer could make you hate Ford cars and a lousy ISV could make you hate the OS - it goes to show that you can't always please everyone.

The way the article was written, it would appear that someone wanted to pump up Microsoft but that's not so surprising is it?

Craig

On Thu, 29 Sep 2005, Lamar Owen wrote:

Oh, quick quiz: what happens to a CentOS box when you reboot after running out of disk space on the / filesystem? You get a graphical login just fine, but then you can't login (you login, and it returns you to a login). Not hard to fix, but very mysterious to the newbie.

I lost my Revelation password database because a disk-full condition recently. An 2 week old backup didn't have some important passwords.

Same has happened with Gaim buddylists, Mozilla/Firefox/Galeon bookmarks, history and passwords, rrdtool files, and many more...

Most Unix programs trash/corrupt files when they save data and the disk is full. The real bad thing is that the user only finds out when it is already too late and irrepairable.

BTW A tool that mails out when the disk is full is not a good solution...

Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

This is a script I use on all my machines. Feel free to hack as required.

#!/bin/bash

# the warning limit for disk usage in % DISK_USAGE=85

report() { echo $* # logger $* }

# check disk usage full=0 for i in $(df | grep "/dev" | cut -c52-54) ; do if [ $i -ge $DISK_USAGE ] ; then full=1 fi done

if [ $full -gt 0 ] ; then report "Warning: disk nearing capacity on `hostname`" df fi

# check in use file handles count=$(cat /proc/sys/fs/file-nr | cut -f1) limit=$(cat /proc/sys/fs/file-nr | cut -f3)

# do a simple check for 3 / 4 usage count2=$(expr ${count} * 4) limit2=$(expr ${limit} * 3) if [ ${count2} -ge ${limit2} ] ; then report "Warning: file handles nearing limit on `hostname` ( ${count} out of ${limit} )" fi

# check allocates semaphore arrays eval `ipcs -ls | grep "max number of arrays" | tr -d " "` eval `ipcs -us | grep "used arrays" | tr -d " "` #echo $usedarrays #echo $maxnumberofarrays

count=$usedarrays limit=$maxnumberofarrays

# do a simple check for 3 / 4 usage count2=$(expr ${count} * 4) limit2=$(expr ${limit} * 3) if [ ${count2} -ge ${limit2} ] ; then report "Warning: semaphore arrays nearing limit on `hostname` ( ${count} out of ${limit} )" fi

cat /proc/meminfo | grep ^Swap: | awk 'BEGIN {n = 3; d = 4} {total = $2 / 1024 ; used = $3 / 1024; if((total * n) < (used * d )) { printf "Swap usage is over %d/%d\n", n, d}}'

Lamar Owen wrote:

On Friday 30 September 2005 04:21, Dag Wieers wrote:

...

On Thu, 29 Sep 2005, Lamar Owen wrote:

...

Oh, quick quiz: what happens to a CentOS box when you reboot after running out of disk space on the / filesystem? You get a graphical login just fine, but then you can't login (you login, and it returns you to a login). Not hard to fix, but very mysterious to the newbie.

...

I lost my Revelation password database because a disk-full condition recently. An 2 week old backup didn't have some important passwords.

Yeah, I lost some e-mail filters once that way, too, when my /home partition filled up. A 'high-water' mark utility probably has been written, and I know logwatch can do periodic e-mails that, if you take the time to read them, can give you advance notice of a disk full impending, but there are those times when the disk might get full quite suddenly (particularly the /var partition if something creates log spew (which, with SELinux, can happen extremely quickly)).

...

BTW A tool that mails out when the disk is full is not a good solution...

No kidding.

Alfred von Campe wrote:

John:

...

This is a script I use on all my machines. Feel free to hack as required.

#!/bin/bash

[snip]

cat /proc/meminfo | grep ^Swap: | awk 'BEGIN {n = 3; d = 4} {total = $2 / 1024 ; used = $3 / 1024; if((total * n) < (used * d )) { printf "Swap usage is over %d/%d\n", n, d}}'

Be careful, this will no longer work in CentOS 4 because the format of /proc/meminfo has changed.

Don't you hate that. I'll change it to extract values like the rest of the script.

It is not that big a problem though, because I have found that if a machine gets to 3/4 swap usage it is going down big time and a warning email is not going to save it. Any email you send about the problem won't delivered until after you give the box the big finger... especially if the machine is your mail server.

John.

Alfred

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Jim Perrin wrote:

On 9/28/05, Ken kenkensmile@netscape.net wrote:

...

Dear CentOS,

Ken wants you to know about this story on http://www.theage.com.au.

Personal Message: How much did MS pay for the article?

Linux misses Windows of opportunity

September 27, 2005

URL: http://www.theage.com.au/articles/2005/09/26/1127586780339.html

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

Lies, Damn Lies, Statistics, and now this.

Now while I'd probably have to spend days dissecting the fallacies contained within that digital snot-rag with my boss, I'll not bore the people here except to again reiterate:

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHA

-- Jim Perrin System Administrator - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Funny though, you cannot add comments at the bottom of the article so that they would be visible to anyone, but you can only "react" via email.

Cheers