cfexecute Cannot allocate memory

[Guest]

I'm running Coldfusion MX9 on Redhat Linux ES5.

After a couple months of running successfully, I started getting an error when running cfexecute

<cfexecute name="/usr/bin/zip" arguments="-j file.xml.zip  file.xml">
</cfexecute>

An exception occurred when invoking an external process. The cause of this  exception was that: java.io.IOException: Cannot run program "/usr/bin/zip":  java.io.IOException: error=12, Cannot allocate memory.

Coldfusion is only using about 50% of its allocated 8GB of memory in the JVM. If I restart it fixes the problem, so I'm not sure where else it is using up memory that cfexecute can't access. No other tags are giving me trouble.

Anyone seen this issue before and have a solution. I'm trying to avoid restarting CF.

Thanks,

Carlos

[Kaotic101]

I'm having the same issue as well, sad to say though that no one posted any replies. Now running Coldfusion 9 under Cent OS 5.5 x64 and receiving the following error.

An exception occurred when invoking an external process.'  faultDetail:'The cause of this exception was that: java.io.IOException:  Cannot run program "/local/libdmtx/bin/dmtxwrite": java.io.IOException:  error=12, Cannot allocate memory.'

This worked for the last two years under Coldfusion 8 using Cent OS 5.3 x32 but as soon as we did the upgrade to both the OS and Coldfusion I seem to receive these left and right. Did you ever figure out a fix for yours?

[Guest]

Hi Gary,

I have not figured this out yet, except that I just used the cfzip tag instead for this instance. cfexecute still won't work for any system commands I try running.

[Kaotic101]

Heh... We were having other weird issues and so we dropped back down to Coldfusion 8.1 x64. As soon as we did that, a million things just started magically working again (including cfexecute). I don't think Coldfusion 9 is as "stable" as they claim yet.

[Guest]

An update on this issue. This not only affects cfexecute, but any tag that performs a system command. For instance, we just discovered that using cfdirectory and the "mode" attribute doesn't work. We tried setting mode="775" and it always does 755 instead.Same thing with CFFILE.

Restarting CF fixes this, but as time goes by the same error occurs. Something else I did before restarting CF was to flush the Linux swap space. We have 2 Linux servers and we noticed one of them wasn't having this issue. The only difference we could tell was about 50% of the swap space was being used on the affected machine, while the working maching had less than 10% used. We issue a swapoff and swapon command. Maybe this will help someone else too.

[Guest]

We were able to fix this, but don't know if what we did is safe. Maybe someone with more Linux and Java experience can answer.

Try this at your own risk.

Setting the file  /proc/sys/vm/overcommit_memory from 0 to 1 fixed the problem. We did this to update it:

# echo 1 > /proc/sys/vm/overcommit_memory

We're still doing research to see if there are any drawbacks to this. 

This page has some information on what the above does:
http://www.win.tue.nl/~aeb/linux/lk/lk-9.html

It seems we are allowing any process to allocate memory no matter what. Possibly setting it to 2 and using the overcommit ration settings are safer as the article suggests. I will play with that later.

I'd suggest searching more on /proc/sys/vm/overcommit_memory before trying the above. 

Hope this helps others. 

Carlos