[Mono-osx] Active Directory Infinite Loop

Sat Apr 21 16:32:21 EDT 2007

Hi Eoin,

I was curious, so I made a test.

When executing a "hello world" C# application using an AD user with  
long uid, I got instead this output:
** (test.exe:389): WARNING **: _wapi_shm_semaphores_init: semget  
error: Permission denied key 0x4d04016b - trying again
** (test.exe:389): WARNING **: _wapi_shm_semaphores_init: semctl init  
error: Permission denied - trying again

These two lines kept appearing 9000 times (so I had about 18000 lines).

Then the error message changed:
** (test.exe:389): CRITICAL **: _wapi_shm_semaphores_init: semget  
error: No space left on device.  Try deleting some semaphores with  
ipcs and ipcrm

I stopped after counting 17 million lines. Then no mono application  
ran, even logged in as local user.

Kind regards
jaume

On 17 Apr 2007, at 11:46, Eoin Norris wrote:

> is there any reason why this is an infinite loop? Someone with an AD
> account complained about a huge log file which caused a system crash
> ( he said although I doubt that was the only reason). The mono layer
> seems to just keep trying to open the wapi file and keeps failing.
> Does the loop not bail out after a a number of failures and abort?
>
> -- Eoin
>
>
> On 5 Apr 2007, at 15:33, Daniel Abrams wrote:
>
>> I appreciate this, it is at least some workaround, unfortunately in
>> most cases these settings seem to be only available to a user with
>> administrative rights, and having to manage each of these settings
>> individually for each user on each machine would be a non-starter for
>> most institutions, as they use LDAP and active directory to avoid  
>> this
>> sort of management.
>>
>> But, its at least useful for getting started on a developer machine,
>> so much appreciated, thanks!
>>
>> In general, I remain of the opinion that this needs to be fixed  
>> before
>> Mono is useful as a general deployment environment on OS X, but I
>> understand those who don't have users with active directory accounts,
>> don't have an issue.
>>
>>
>>
>> On 4/5/07, Jaume Llardén Prieto <jllarden at aim.com> wrote:
>>> Hi,
>>>
>>> There's a workaround: define the UID and GID in Directory Access.
>>>
>>> The whole process is:
>>> Open Directory Access in Applications/Utilities, select Active
>>> Directory in panel Services and press Configure. In the Advanced
>>> Options, choose tab Mappings and choose a mapping. For my test I
>>> chose UID to map to postalCode, UGID to primaryGroupID and GGID  
>>> again
>>> to postalCode (I needed a numeric attribute to play with and
>>> postalCode was good enough). Then bind and you're done.
>>>
>>> I chose low values: uid=4055, ugid=513 and ggid=4055. And my
>>> 'test.exe' worked. Without this workaround I suffered the described
>>> problems.
>>>
>>> The catch is that you have to change the uid/gid of the home
>>> directories of the affected users locally on every Mac.
>>>
>>> Kind regards
>>> jaume
>>>
>>> On 4 Apr 2007, at 17:11, Daniel Abrams wrote:
>>>
>>>> uid=435092441
>>>> gid=1309106314
>>>>
>>>> On 4/4/07, Eoin Norris <e.norris at mac.com> wrote:
>>>>
>>>> If you are running on an active directory account what is your gid
>>>> and uid - the result of ( as you prob. know) typing id in the
>>>> terminal?
>>>>
>>>> -- Eoin
>>>>
>>>> On 4 Apr 2007, at 15:57, Daniel Abrams wrote:
>>>>
>>>>>
>>>>>
>>>>> On 4/4/07, Eoin Norris < e.norris at mac.com> wrote:
>>>>>
>>>>> Well, my application is generally home-based but I would kinda
>>> think
>>>>> 15% of all users high, though it may be 15% of all macs deployed
>>>>> across  "schools, colleges, companies, government" but whatever
>>> about
>>>>> schools macs in the enterprise are extremely rare. So the total of
>>>>> all macs is lower.
>>>>>
>>>>>
>>>>> Perhaps.  I worked for Apple in what was the Enterprise and
>>>>> Education divisions, and I think my numbers are pretty
>>>>> conservative, but maybe the ratio has shrunk.  I can tell you that
>>>>> one of my current clients is a large government agency, and macs
>>>>> are not as rare as you might think, and they all use active
>>>>> directory authentication.
>>>>>
>>>>>
>>>>>
>>>>> It is an issue for deployment as well. I am getting reports in the
>>>>> field. I dont know specifically where to look in the Mono code
>>>>> ( where it is happening) but the thread below ( taken from this
>>> list)
>>>>> gives some examples. The original poster does not seem to be on
>>> the
>>>>> list anymore, or not contributing to this new thread on the same
>>>>> issue, but might be available on that email address.
>>>>>
>>>>> http://lists.ximian.com/pipermail/mono-osx/2006-January/
>>> 000444.html
>>>>>
>>>>>
>>>>> He clearly did some research and ascertained that it was an Apple
>>>>> bug.
>>>>>
>>>>> I can't say if its an Apple bug or not.  I could certainly believe
>>>>> that POSIX threads are done differently in Mac OS X than in Linux,
>>>>> and that the Apple implementation is incomplete or buggy, I don't
>>>>> have much experience in that area.  But I do know that in higher
>>>>> level environments, Java, ObjC, etc, thread and process management
>>>>> work fine on OS X and that many other development and deployment
>>>>> environments have managed to solve threading issues without dying
>>>>> early on Mac OS X.  Unless it's solved, it effectively rules out
>>>>> Mono development for us, but I understand that your mileage may
>>> vary.
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mono-osx mailing list
>>>> Mono-osx at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>>
>>>
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx