I have a 64-bit server running linux 3.x that reports "bash: fork: cannot allocate memory". This server has plenty of RAM (64G) and swap (128G) and I cannot see a particular process being the culript (no apparent memory leak).

I was not limited by "ulimit" as nothing was running under this shell, and the problem also existed as root. It is slightly complicated to debug a server when even typing top or cat /proc/whatever fires "bash: fork: cannot allocate memory" 95% of the time.

A few check I already did: - some memory was remaining (total allocated space less than swap space). - no ulimit - no clear issue, no messages in log, no messages in dmesg - virtual memory not exhausted (as far as I checked)

What should I check when I encounter this same problem again ? What can be the causes of no possible memory allocation apart ulimit / limited swap space / non exhausted virtual space ? Of course a reboot solved the issue (for now) but I am pretty surprised by this issue.

  • Even ulimit -a shows unlimited to max user processes, virtual memory and file locks? (last 3 lines of the output). On my workstation for example, i have the max user processes (-u) 62636 and this could be a problem but a good way to limit the action of a fork bomb... – user34720 Jan 5 '15 at 22:45

I believe the issue to be related to a Windows mount request gone bad. When the Unix forked process gets the message back from Windows, there appears to be a fumble of sorts.

This dominoes into other realms where resource "A" is requested directly or indirectly. I've seen it most recently with respect to VM related events.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.