A client keeps getting the following error at login

Red Hat Linux release 6.1 (Cartman)
Kernel 2.2.12-20 on an i686
Login: d3logon
Password:
Last Login: Fri Feb 23 08:35:54 from *********.com

Bash: fork: Cannot Allocate Memory



This occurs on dirrerent telnet sessions, whilst other users are logged in.



Any clues?

"Jon Dempsey" wrote:

Wow, that system is about 6 years old!


This is a common issue reported from time to time. It may have
nothing to do with D3. Here are some causes:
1) Too little swap space.
2) Corrupted disk under swap space.
3) Conflicts between apps like postfix and squid.
4) A memory leak in some software, may or may not be D3.

You might be able to get around the problem if you restart individual
non-MV processes until problem goes away.

It's a fair chance that the disk may have taken a hit. With a Mean
Time Between Failure rate of maybe a couple years, that system seems
overdue for some bad sectors.

Because of this, I don't think you should reboot the system yet in an
attempt to flush memory. Someone please correct me if I'm wrong here
but I think restarting with bad disk in the swap area with only cause
boot errors. Another mkswap can be done but let's not go there for
now.

My advice is to get everyone off the box and get at least one good
file-save to tape, preferably two. If they backup to disk then ensure
that the backups are exported off this hardware. Then come back here
and see if anyone has any more intelligent advice.

HTH
T

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Thanks Tony. I was sortof hoping no-one would write that sort of reply as
it's been a few years since I loaded that system and I may have a problem
looking up the original installation notes!!!!!!

Anyone fancy a trip to Livingston, Scotland?

"Jon Dempsey" wrote
[[ A client gets, at login, ]]
[[ ]]
[[ Bash: fork: Cannot Allocate Memory ]]


<snipped some sage advice to shorten this>



"Jon Dempsey" wrote
Urgh, I'd choose to back up the data and then fix the drive, then put the
data back. Plus, you'd have some hope of keeping your activation(s) on
loaded software, if you were very careful and lucky. And could you coax
them to extract and mail you the disk instead of you trudging to Scotland?
Maybe hire a local to plop in a fresh power supply, clean out the dust bunnies,
clean the cpu fan and heatsink? Put working batteries in their UPS?

By 'data', I mean all disk contents other than swap storage. The
dd command, or better yet, commercial 3rd party backup software, can help
you avoid a 'reload and retweak' marathon. Not like a redhat 6.x box is
going to have very big hard disks anyway...

And yes, fix. The easiest fix is 'repair by replacement' -- where you put the
same data back on new [, or on replacement used] media, but sometimes you
get relief from a scsi low-level format, or just detecting the happily few, and
not-multiplying, bad spots and thereafter avoiding their use.

Linux has facilities to detect and bear with bad disk blocks {at least on
efs2/efs3 filesytems -- see man pages for e2fsck and dumpe2fs} Beyond that,
you could test a swap partition by making it efs2 just for the duration of the test.
This all assumes you've got some way to boot into linux from some other,
known good, disk or cdrom to do all this work, and have a loaner disk to
store the data.