Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=77856 --- shadow/77856 2006-03-20 10:00:51.000000000 -0500 +++ shadow/77856.tmp.17532 2006-03-20 11:59:42.000000000 -0500 @@ -46,6 +46,67 @@ Whenever (either concurrently or consecutively) any other mono application is run by the same user, the same semaphore will be reused. The ID to this semaphore is stored in a file in ~/.wapi which holds shared state. This semaphore is used for cross-process synchronisation in the windows api emulation layer. + +------- Additional Comments From [EMAIL PROTECTED] 2006-03-20 11:59 ------- +Additional information from irc conversation: + +<dave_largo> Dick: Morning....so I see your note in that bug report. +<dave_largo> Dick: So the server has 750 unique people logging in and +out all day. +<Dick> dave_largo: am i correct in thinking that you're using a large +terminal server, and that when many users have each started a mono app +your server has then run out of semaphores? +<Dick> snap +<-- cody has quit (Ex-Chat) +<dave_largo> Dick: No space left on device. Try deleting some +semaphores with ipcs and +<dave_largo> ipcrm +<dave_largo> Dick: We didn't even close to simulating our concurrent +capacity and the server was having problems. +<Dick> as a preliminary stopgap, i think you can increase the number +of semaphores available to the kernel +<-- barbosa has quit (Leaving) +<Dick> logging in and out shouldn't affect this particular problem +unless you are deleting the files in ~/.wapi +<dave_largo> Dick: It seems sloppy to me to have anything allocated +after a user logs out. Am I not seeing the big picture? +<Dick> i see what you're saying +<dave_largo> Nothing in Unix ever works that way, with any user space +still being allocated after they log out. +<-- Lukas has quit (Read error: 104 (Connection reset by peer)) +<Dick> the job the semaphores are doing used to be handled by a +separate mono helper process, which gave us a different set of issues +<dave_largo> Dick: When things work this way it causes problems in a +shop such as ours, we we try and put something into a script to +release them upon logout, that doesn't always work either because +sometimes people just turn off equipment without logging out. +<Dick> ok, i was just about to suggest running a cleanup tool at logout :( +<dave_largo> Dick: yeah people turn off their thin clients at the end +of the day without logging out and the scripts never complete. +<dave_largo> Dick: Things need to be designed for poor technique :) +<Dick> the problem is that we're trying to emulate a set of semantics +that doesn't map well to unix +<Dick> so its not a case of process A forks process B and waits, and +cleans up +<dave_largo> Dick: I'm not sure how Evolution is using mono, but it's +linked into 2.6 for some reason. +<dmoonfire> Anyone play with DOAP? +<Dick> im not sure what evolution is using it for either +<ankit> *maybe* for evolution-sharp? i could be wildly off-track though.. +<dave_largo> Dick: So it seems to us that it's not even close to +being able to run the capacity that we need it to. We go like 20% of +capacity logged in and the server was having problems. +<Dick> i need to figure out a way for a mono process to know reliably +that it is the last one running (per user), and then i can delete the +semaphore +<dave_largo> Dick: We would have to tune semaphores up to a massively +large number. +<Dick> ankit: evolution-sharp is for talking to evolution-data-server, +so other tools might be using it for that +<dave_largo> and I thought semaphores were dynamic in 2.6 kernel, and +were allocated as it needed them. +<dave_largo> or is an issue of bumping up that /dev/shm file system? +<Dick> dave_largo: i'll need to have a think about how to proceed _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
