DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30627>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30627 possible bug in handling ALARM signals on Solaris 9 ------- Additional Comments From [EMAIL PROTECTED] 2004-08-13 18:15 ------- As far as having the signal delivered on the wrong thread: Threaded plug-in modules need to block the asynchronous signals which Apache uses (SIGALRM, SIGTERM, SIGHUP, etc.) on threads they create in order to ensure that the signals used by Apache are delivered on the thread which Apache knows about -- the main thread. That's a restriction on threaded modules for all the Unix-ish platforms. (I can't comment on whether or not the alarm signal happened to only be sent on the main thread prior to Solaris 9. There's no capability for the Apache parent process to pick a thread anyway.) As far as fcntl returning an error: There have been such failures for years with threaded plug-in modules on Solaris. The recommendation is to switch to "AcceptMutex sysvsem", but note that you'll need to bump up the number of kernel semaphore undo structures and reboot as the default Solaris sysdef on that is not sufficient for Apache. The sysdef command displays the semaphore stuff. You need an undo structure (SEMMNU) per possible Apache child process, as well as enough for all other applications on the system. This is configured in the file /etc/system with set semsys:seminfo_semmnu=500 (or whatever; should be > MaxClients) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
