SQL Anywhere client libraries and servers use SYSV semaphores on most Unix platforms (Solaris is an exception). The semaphores are used to perform signalling actions across client and server processes.

There are a number of ways that semaphore can be 'leaked':

• a process is killed using a signal that does not allow the process to 'clean up'. E.g. kill -9
• a client application (or associated library) installs a signal handler after SA's client library has installed its handler, and the application's signal handler does not properly chain execution to SA's handler when a signal occurs... and then the client crashes with the net result that SA's client does not get a chance to cleanup.
• a client application (or any loaded library) causes the program to halt in such a way that the library 'unload' handlers do not get executed. One known issue is if the client calls _exit() instead of exit().

There are possibly other ways that semaphores can be leaked but the above are the most common tha twe have seen. For example:

• Apache is known to kill child processes using SIGKILL (kill -9) and therefore semaphores can be leaked and thus cause a problem over systems that run non-stop for several weeks or months.
• We have seen some Java applications / scenarios where the the JRE (or related code) will use _exit() to terminate itself thus causing semaphores to leak if the SA JDBC was being used. (I can't remember the exact details?)
• We have seen some third party libraries that customers have used that have installed signal handlers and these handlers were not written in such a way as to properly chain signal handlers.

I am not that familiar with Tomcat so I do not know if any of the above applies to your situation. If you are running Tomcat within an Apache process then the first known issue could be what is causing your semaphore leak.

FWIW: We have had discussions within SA engineering about possible method(s) of working around the above known issues. Many times we are able to work with the application developer(s)/customers to resolve the issue by having their application modified (e.g. correct their signal handlers to chain handlers). Sometimes there isn't any better solution other than to ensure that the semaphores periodically get cleaned up by a process that monitors the number of semaphores in use and then performs a clean up process when the limit is near. I.e. To clean up: (a) stop the Apache/httpd server, (b) delete all semaphores owned by the user that run Apache, and then (c) restart the Apache/httpd server.

Do you have any processes that are crashing? Those are the leading candidates for leaking SYSV semaphores.

You can check ipcs -p to get a list of the currently allocated semaphores on the system, and see which username / process id has them allocated. You can use ipcrm -s semid to remove unneeded semaphores on the system to try and avoid rebooting.