[Mono-dev] xbuild - ** ERROR **: shm_semaphores_init: semget error: No space left on device.
Arne Claassen
arnec at mindtouch.com
Fri Nov 12 13:27:27 EST 2010
Sounds like i just need to build 2.8, since more and more things i run
into seem to be taken care of in 2.8.
This is going off-topic, but it's something that I haven't gotten a
handle on yet with mono release process:
Is 2.8 the new stable or still in flux? If it's stable, when might
there be rpms or at least an RPM spec.
Basically, I don't want to build from source for every server i set up
and I want to make sure every server runs identical code. This is why
I've been sticking with 2.6.x, assuming it's still the stable and
fixes would still trickle into it. Is that not correct?
If I can help with building or testing RPMs and their specs for 2.8,
let me know, I know that there's always tons to do and too few people
available to do it.
thanks,
Arne Claassen
MindTouch
San Diego, CA
http://twitter.com/sdether
On Nov 12, 2010, at 10:10 AM, Robert Jordan wrote:
> On 12.11.2010 19:06, Arne Claassen wrote:
>> I can try that. But more importantly, I'd like to learn more about
>> about semaphore usage.
>
> Their usage has been faded out in 2.8.
>
>>
>> I'm just wildly speculating, but i assume it sets up a new one for
>> IPC
>> when an application gets compiled into a new appdomain by ASP.NET
>> when
>> it detects code changes. But shouldn't those semaphores get released
>> when the old appdomain gets unloaded? Is this a sign of appdomains
>> not
>> being unloaded or just not cleaning up their semaphores? And
>> shouldn't
>> they all get released regardless when the mod_mono processes gets
>> shut
>> down?
>>
>> Would love to get more insight into what's happening, but don't
>> really
>> know where to start.
>
> Have a look at mono/io-layer/, but, as I wrote, they are not
> enabled by default anymore.
>
> Robert
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list