Big instability? (Consistant BSOD type Hang)
 

RH Enterprise v3

Fresh install on new/stable hardware. When I browse the /proc directory using the gnome console, the system either NEVER populates the directory OR hangs immediately.

It is an instant solid hang as well (equivalent to a BSOD). The cursor/screen freezes right up. The keyboard is un-responsive (even to C-A-D), and any remote connections (even SSH terminals) immediately freeze/timeout.

I am like so shocked.

This system has been under heavy testing for the past week WITHOUT a single incident until i did a fresh install - which I have done two now. Since the last install, it seems to be perfectly viable - as long as I stay away from the /proc directory.

I think that is the answer - stay away from /proc. I once backed up a whole filesystem to tape, then made the mistake of restoring it - which included the /proc directory. No surprise, my system was so badly messed up by this that I had to reformat and reinstall everything (Rh 6).

What might be happening is that when you browse the /proc folder / directory, GNOME might actually be writing stuff in there - which your kernel won't like. If you want to browse the /proc folder, why not use an xterm and cat all the files you want to examine? Might be safer.

Well, of course, I have no NEED to use gnome to browse the /proc directory - but its an easy thing to do incidentally (which is how I found the problem in the first place).

So, just because you accidentally let your cursor wander over this danger spot - bamm, the system is down? That is a really, really, really, really bad thing - esp on final release/tested/registered software.

I would have to say this looks to me to be the biggest bug in a released OS since the Lisa - where you could rather easily delete your entire OS by putting the wrong folder in the trashcan.

This is exactly why access outside /home/user is restricted to root. Before you go playing in system files you better know what you are doing. Most experienced admins never use a gui as root and are very anti the whole concept for the very reason you have described. There is nothing in /proc that you need so don't go there. The latest kde 3.3 won't allow the creation of a root login. There is nothing unusual in this at all. It is present in every os.
If you want to see what is hapenning as regards a running system open a console and issue the command top. This will list all the running processes and if you are root and have a process that is causing problems you can kill it in top.

I hate to get belligerent - but that position is 100% in-defensible. There should not even be an argument/discussion on “well don't do that”.

Here is my point – there should not be BSOD button. Period. There are no excuses against this idea. If there HAS to be a BSAD button – it should be at least LABELED! Is that a lot to ask for a GUI? Like a dialog box or a warning – hey, if you click <this> your system is 50% likely to crash. Am I completely crazy here?

The only argument I can see is about the proper fix to this defintie BUG – a dialog box, a filter, a label, a warning -etc. Anything else is mush.

A free reign BSOD button is incomprehensible and I really don't see how people can be so complacent about the subject.

I agree that, if this is correct, that is a SEVERE bug that must be fixed. I didn't see him mention he was browsing /proc as root. Any user can read 80% of the content of /proc. (I.e., /proc/cpuinfo).

There is no excuse for the system to hang for browsing proc in a GUI. "Real admins don't use GUIs"... not an excuse. Suggesting "just stay away" from it is the Microsoft answer.

While I'm not sure what causes this, I can browse /proc using a GUI just fine. Does /proc have any problems from the command line? Perhaps gnome is trying to create some sort of file in /proc: that could be problematic.

Actually, I was logging in as root - I mean, I was still installing the freaking system - I hadn't even set-up another account yet. And RedHats install - RPM update stuff is very GUI - mozilla for registering - RPM updates and installing additional features.

And like I said, its not that I needed to go to /proc, I just clicked the wrong thing by ACCIDENT and bamm - the system crashed like there was no tomorrow.

If /proc is so volatile under a GUI, its should have SOME safeguard.

Even the military puts big red covers on dangerous switches.

I'd blame that on nauseous and it's preview-feature ...
You can reproduce that behaviour in a console as
well, try to have a look at /proc/kcore using less ...

Note: only "hangs" my older boxes ... in reality it's
just the CPU being VERY busy, and it will come
back, eventually ... on my P4 systems it doesn't
matter.


That all said: someone who uses Gnome as root
should be shot in the first place ;) ... and the safeguard
is not to use a GUI to do admin-tasks.



Cheers,
Tink

Um - yeah thats the answer - esp in the newbie section.

This is on a dual Xeon 3.06g system with 1g of memory and I let it sit for up to 45 minutes, so, I would chalk it up to more than being busy.

And one can't emphasise it enough, glad you agree!

Well, in this case there's more good reason not
to use Gnome?


Cheers,
Tink

Really thats balderdash. Throw the baby out with the bathwater?

Is a filter THAT much to ask for? A dialog box that simply says – "are you sure you want to do this?"

You consider that unreasonable? This is the REAL world after all.

In all honesty ... as non-root user nothing would
have happened, since you (in any sane distro,
anyway) wouldn't have permissions to look at
some of those (namely the critical ones) files
in /proc. .... and since this is the real LINUX
world, and not the shiny pointy-clicky "ask me
30 times whether I'm sure I want to do this"-
windows world (which makes administration for
real-world admins a night-mare) I'll emphasise it
again for the prospective root users out there:
"Don't use X as root!!!" ... and if you are going to
do ANYTHING as root: stop, think twice; if you're
not certain, don't do it; don't jump to conclusions
or make assumptions based on experience with
windows: Linux will do as it's told, even if what
you tell it is stupid ...

And the best advice I can give you specifically
in this context:"Learn from mistakes! Don't use a
graphical file-manager when you're root!" :)

And as far as Balderdash goes - you're using the
wrong tool as the wrong user at the wrong time in
the wrong place. Be you everyday self in X, and
as root learn to use the shell.



Cheers,
Tink

Can we please try to apply some logic to your argument. Since a REAL administrator wouldn't be using gnome as root, my bug fix wouldn't effect them in the slightest. Which makes your entire argument moot.

TRUST me I know where you are coming from and I UNDERSTAND your point of view. Its a nice attitude for the LAB, but it has no place in the real world. When I develop in some mamby-pamby HLL like 'C', its just as irritating. I'll setup data structures and supporting modules and build it JUST to make sure everything is linking properly and bamm – there is some childish error – warning no OBJ file made. Well no-freaking duh.

That is why assembly is the best shit in the world. It will let you do any stupid thing you want. Thats why all real programmers program 100% in assembly. But yeah, when I think like that – like the way you are thinking now- I realize, ok, I am not the only person in the world.

I'm not suggesting Linux/Gnome behave the way I want it to (that is in fact what you are doing). I am suggesting it behave in a reasonable, responsible, seriously professional manner and not like something developed in someone's basement. If Gnome can't handle root – then it should dismount on a root login. If it allows a root login, then it needs to be stable.

Like it or not, without a GUI, Linux would be a novelty. The power of the Linux kernel has developed because it has leveraged the power of Gnome and KDE. The Linux kernel, however, strives to be ROBUST. Robust software MUST do error and boundary checking – that is what actually makes it robust. When that software is a user interface, it either needs to prevent a user from doing unstable things or at least have a road sign. ANYTHING less is poor/buggy design.

Linux isn't in the lab anymore. Its trying to grow up. It wants to be stable. To do these things it requires a stable GUI – like it or not.

This is unfortunately where you are totally wrong. Linux hasn't been leveraged by gui rather the gui has been placed on top of the os to cater for a small section of the market for desktop use. Linux derives its heritage from Unix and as such it is designed for cli usage. You may think that a gui interface is what is important today but you would be wrong since the major deployment of the os is not on the desktop but on the server. You may not like what I am saying and come back with the argument about the expansion on the M$ desktop but the truth is that Linux's power and major deployment is in the server environment and it has been very successful.
To come back to your original problem. To understand what the problem is with this so-called "bug" of yours it would be easiest to explain it using a human interface situation. If you were in a lecture and the lecturer was was speaking fast and you had to listen and take down everything he said verbatim your brain would quickly lag behind in processing the info, even if was capable of processing 2 separate processes simultaneously. Because you would be incapable of writing as quickly as the information came in, the written piece would lag far behind what is being said. This is the same situation here. The internals of the system are processing normal processes and in addition you are requiring the system to report on the the report i.e. getting processes to report on processes. The system is incapable of reporting on itself instantly and therefore it goes into information overload and will require some time to recover.
I think you are just being argumentative here.

Honestly,
I am just shocked that anyone would defend what is clearly a bug. In this case, calling me argumentative, is the pot calling the kettle black. The ONLY excuse for this behavior (in the GUI) to be permissible is if the development team was unaware of this possible situation. That is it. There is no other argument.

If they (the development team) understand what does/doesn't happen then it is required by acceptable software design practices that they at least put up a warning. Its really not all that complex or even difficult to understand.

It's comparable to not writing a divide by zero error handling routine by arguing that no real program would ever divide by zero. Its a non-argument. Its not a defense to say – well you can't divide by zero so no one will ever do it. UGH – that is the ENTIRE reason to make error handling and boundary routines to handle non-standard situations that make the system unstable.

So – maybe you guys know how to administer a Linux network – great. Thats is a brilliant accomplishment actually. But this goes to the subject of stable/solid software design. Under this subject, you need to do some more fancy book learning.

As to your argument against a GUI, it may seem to have merit, but it discounts the entire idea of volume. The masses cut their teeth on a GUI and then get use to the underlying processes later. It makes the OS more available to a wider audience that, once they are more familiar with the OS, can then act to administer and implement it in more significant ways.

For example, large corporations only started to seriously consider Linux as a viable solution once a large pool of trained and experienced administrators was available. If a GUI was not important, even if not just for a starting point for new users, other, crappier Oses simply would not have a place in the market. With a GUI, DRDOS and Novell would have ran MACOS and Windows out of business. The only hindrance of the first two was their lack of a GUI and the only real advantage of the last two – their GUI. Additionally, what other explanation is there for the Linux domination over FreeBSD?

To deny the importance of a STABLE GUI, as an OPTION, is to run around with your hands on your ears and scream “I can't hear you”.