Rikard, On Thursday 26 August 2004 23:18, Rikard Johnels wrote:
...
My apologies Randall. I missed some cutting as i replied. :(
No problem.
And as i stated in another post, i have tracked y2base as a possible candidate. It peaks at 99.5% and about 1/4 of a second later the system is hung.
Dont know why it races like that, but that is the last thing i see as i monitor the system.
All after the init of y2base is lost as all connections to the box dies. No keyboard, no network, frosen display.. the works.
I have seen misbehaving programs hog all physical memory, gradually crowding out all others, including those that do things like reflect mouse movement in the cursor and all running X application's drawing (and / or the X server itself). The net appearance is of the system locking up, but in fact it's working furiously--at nothing useful. It's extremely frustrating because it can take minutes to get the monitor to switch from X to a virtual terminal screen (ALT-F1 through ALT-F6). Most of the time, this ends in the errant process being killed by the kernel because it's ongoing demand for more memory eventually cannot be satisfied. I was going to suggest that you might try running that task with some limits (memory, specifically), but apparently Linux (at least up through kernel 2.4) does not support the ulimit system call and the user-level mechanisms for accessing it. Email traffic on some of the Linux developer's lists suggests it has been implemented, at least in part, in very recent 2.6 kernels (2.6.8), so maybe when SuSE puts out the update that fixes the known problems in the latest (2.6.7-7.104) that functionality will become available (assuming all the other pieces necessary to access it are in place).
-- /Rikard
Randall Schulz