[Mono-bugs] [Bug 77856][Cri] Changed - Mono Runtime Is Leaking Semaphores

[bugzilla-daemon at bugzilla.ximian.com]

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 drichard at largo.com.

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 drichard at largo.com  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