1

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.

Improve this question
1
  • 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
    Commented Jan 5, 2015 at 22:45

1 Answer 1

Reset to default
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .