Sun 12 Jan 2014 02:57:39 PM EST | SETI@home | [error] ACTIVE_TASK::start(): can't create memory-mapped file: shmget() failed

Ever since about Christmas, it seems my computer has bee running into this error. I is very rare for it to process 2 v7.01 tasks at the same time. (I have 2 cores with 2 threads available.) BOINC manager says simply "Waiting for shared memory". I looked into this error and I have plenty of shared memory available.

bash-4.2# df -ha /dev/shm
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G   20M  3.9G   1% /dev/shm
bash-4.2# 

So what is going on? I did not make any system changes prior to this error. It just suddenly happened. I am not experiencing this error on my other machines that run the same versions. Machine = WOPR

Thanks

---

-mpyusko

Never seen that before...

Might be a clash for the same s@h app starting up a second time...

Are you on the latest Boinc version?


Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

I don't know how it shows in Linux as I only run Windows at present but if you set the BOINC preference for memory usage too low you will get tasks waiting for memory to become free. Might you have accidentally changed that setting(or perhaps all your memory is not being recognised)?


John.

---

GPU Users Group

It doesn't do it for all the WU's only some of them. For Seti@Home, I keep a 10 day supply of WU's with an additional 10-day buffer. (Otherwise I run dry every Tuesday... plus I used to face regular Internet outages from TWC. They have gotten much better since I monitor my line more closely.) If it finds a WU that is waiting for Shared Memory, then it will skip down the line until it finds one that works. I am using 7.2.28. I have not changed the version for this to happen, like I said before, nothing on my computer changed. It was sitting on it's own for a few days and when I came back to it the stats showed it was fine for a while then suddenly decreasing Average Credit while well fed with WU and widely available computing resources.

WOPR is configured to crunch both of it's 2 CPU cores dedicated to BOINC and the AMD HD6950 swaps between Milkyway@Home and Primegrid. Note: Seti@home was running on the GPU at one point but it did not seem to have any noticeable accelleration so I restricted it to the CPU only to free up resources for the other projects. You should be able to see on the graph, the sudden decline. Pleas also note that I did intentionally switch off computing for a couple weeks when I noticed the problem, and I added Primegrid to the CPU. My logic was to give either figure it out after the holidays or at least flush the WU's and wait until a possible bug-fix and try again.


https://www.dropbox.com/s/0s6fkn2cq5lv7th/SETIatHome.png

Thanks.

---

-mpyusko

You would be far better running your caches set to 3 days minimum buffer plus extra 0.1 day. Setting 10 days plus 10 days will cause you to have to wait an very long time (ten days) to refill after sending work back. Also with the current limits in place there is very little if anything to be gained in having more than three or four days work in hand.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?