Re: [users@httpd] Interrupted system call: Failed to acquire SSL session cache lock
On Wed, Jul 16, 2014 at 1:30 PM, Jeff Trawick wrote: > I won't disagree with you at all Yann, but in the interest of promoting the > idea that you don't actually have to use all the configuration httpd offers: > > If the poster had not made a change from the default based on some > developer's silly comment in the documentation, they wouldn't have > encountered a problem. It is best to leave the mutex type alone unless you > have a specific issue. I agree of course, the default is the most used/tested configuration. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Interrupted system call: Failed to acquire SSL session cache lock
On Wed, Jul 16, 2014 at 7:20 AM, Yann Ylavic wrote: > On Wed, Jul 16, 2014 at 12:49 PM, Jeff Trawick wrote: > > On Jul 15, 2014 8:46 PM, "Tomlinson, Stuart" > wrote: > >> > >> Are there any expected negative impacts from using "sysvsem" instead of > >> "sem" (which I understand defaults to "posixsem" - described in the > >> documentation as "elegant", whereas "sysvsem" is merely "somewhat > elegant")? > > > > Funny developers... > > > > There is safety in numbers (i.e., use what other people on your platform > > use, unless you have a specific problem). sysvsem is the default on > Linux. > > (I assume you are using Linux, but maybe that is not the case.) > > > > Using sysvsem on Solaris with the prefork MPM, you would likely have to > > increase the number of semaphore undo structures (at least in the old > days; > > I can't find my normal go-to reference for AcceptMutex oddities; Eric?) > > SSLMutex/AcceptMutex "pthread" work very well on Linux, and have the > advantage to be "robust" against children crashing while holding the > lock (like sysvsem, unlike posixsem AFAICT), without system limits > (unlike sysvsem). > > This is probably true for all unixes that HAVE_PTHREAD_MUTEX_ROBUST > (ie. pthread_mutexattr_setrobust_np), but I can't verify that. > > Regards, > Yann. > > I won't disagree with you at all Yann, but in the interest of promoting the idea that you don't actually have to use all the configuration httpd offers: If the poster had not made a change from the default based on some developer's silly comment in the documentation, they wouldn't have encountered a problem. It is best to leave the mutex type alone unless you have a specific issue. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [users@httpd] Interrupted system call: Failed to acquire SSL session cache lock
On Wed, Jul 16, 2014 at 12:49 PM, Jeff Trawick wrote: > On Jul 15, 2014 8:46 PM, "Tomlinson, Stuart" wrote: >> >> Are there any expected negative impacts from using "sysvsem" instead of >> "sem" (which I understand defaults to "posixsem" - described in the >> documentation as "elegant", whereas "sysvsem" is merely "somewhat elegant")? > > Funny developers... > > There is safety in numbers (i.e., use what other people on your platform > use, unless you have a specific problem). sysvsem is the default on Linux. > (I assume you are using Linux, but maybe that is not the case.) > > Using sysvsem on Solaris with the prefork MPM, you would likely have to > increase the number of semaphore undo structures (at least in the old days; > I can't find my normal go-to reference for AcceptMutex oddities; Eric?) SSLMutex/AcceptMutex "pthread" work very well on Linux, and have the advantage to be "robust" against children crashing while holding the lock (like sysvsem, unlike posixsem AFAICT), without system limits (unlike sysvsem). This is probably true for all unixes that HAVE_PTHREAD_MUTEX_ROBUST (ie. pthread_mutexattr_setrobust_np), but I can't verify that. Regards, Yann. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
RE: [users@httpd] Interrupted system call: Failed to acquire SSL session cache lock
On Jul 15, 2014 8:46 PM, "Tomlinson, Stuart" wrote:
>
> [ please excuse the poor formatting due to email client ]
>
> > From: Jeff Trawick [mailto:traw...@gmail.com]
> >
> > On Tue, Jul 15, 2014 at 4:55 PM, Tomlinson, Stuart
wrote:
> > Hello,
> >
> > We have experienced this warning/error a few times:
> > [Thu Jul 03 20:17:15 2014] [warn] (4)Interrupted system call: Failed to
acquire SSL session cache lock
> >
> > After this has occurred, the Apache ErrorLog is flooded with these
errors:
> > [Thu Jul 03 20:17:57 2014] [error] shmcb_subcache_retrieve internal
error
> >
> > It looks like there is a bug in the APR library. It doesn't handle
EINTR ("Interrupted system call") in the POSIX semaphore implementation.
>
> Thanks for the superfast feedback. Should I file a bug for this? If so,
should it be filed for "Apache httpd-2" product or "APR" ?
>
No need, I fixed it shortly after I saw your post ;)
Otherwise, "APR" would be the answer...
>
> > SSLMutex sem
> >
> > Use "SSLMutex sysvsem" instead.
>
> Are there any expected negative impacts from using "sysvsem" instead of
"sem" (which I understand defaults to "posixsem" - described in the
documentation as "elegant", whereas "sysvsem" is merely "somewhat elegant")?
Funny developers...
There is safety in numbers (i.e., use what other people on your platform
use, unless you have a specific problem). sysvsem is the default on Linux.
(I assume you are using Linux, but maybe that is not the case.)
Using sysvsem on Solaris with the prefork MPM, you would likely have to
increase the number of semaphore undo structures (at least in the old days;
I can't find my normal go-to reference for AcceptMutex oddities; Eric?)
>
>
> Regards,
>
>
> Stu Tomlinson.
RE: [users@httpd] Interrupted system call: Failed to acquire SSL session cache lock
[ please excuse the poor formatting due to email client ]
> From: Jeff Trawick [mailto:traw...@gmail.com]
>
> On Tue, Jul 15, 2014 at 4:55 PM, Tomlinson, Stuart
> wrote:
> Hello,
>
> We have experienced this warning/error a few times:
> [Thu Jul 03 20:17:15 2014] [warn] (4)Interrupted system call: Failed to
> acquire SSL session cache lock
>
> After this has occurred, the Apache ErrorLog is flooded with these errors:
> [Thu Jul 03 20:17:57 2014] [error] shmcb_subcache_retrieve internal error
>
> It looks like there is a bug in the APR library. It doesn't handle EINTR
> ("Interrupted system call") in the POSIX semaphore implementation.
Thanks for the superfast feedback. Should I file a bug for this? If so, should
it be filed for "Apache httpd-2" product or "APR" ?
> SSLMutex sem
>
> Use "SSLMutex sysvsem" instead.
Are there any expected negative impacts from using "sysvsem" instead of "sem"
(which I understand defaults to "posixsem" - described in the documentation as
"elegant", whereas "sysvsem" is merely "somewhat elegant")?
Regards,
Stu Tomlinson.
Re: [users@httpd] Interrupted system call: Failed to acquire SSL session cache lock
On Tue, Jul 15, 2014 at 4:55 PM, Tomlinson, Stuart
wrote:
> Hello,
>
> We have experienced this warning/error a few times:
> [Thu Jul 03 20:17:15 2014] [warn] (4)Interrupted system call: Failed to
> acquire SSL session cache lock
>
> After this has occurred, the Apache ErrorLog is flooded with these errors:
> [Thu Jul 03 20:17:57 2014] [error] shmcb_subcache_retrieve internal error
>
It looks like there is a bug in the APR library. It doesn't handle EINTR
("Interrupted system call") in the POSIX semaphore implementation.
[Thu Jul 03 20:17:58 2014] [error] shmcb_subcache_retrieve internal error
> [Thu Jul 03 20:17:58 2014] [error] shmcb_subcache_retrieve internal error
> [Thu Jul 03 20:17:59 2014] [error] shmcb_subcache_retrieve internal error
>
> Other symptoms as a result of this condition are significantly increased
> CPU utilization (at least doubled), and increase in time to establish
> connections when trying to use SSL session caching (tested with "openssl
> s_client -state -reconnect -connect server:port"). Apache restart is
> required to restore normal behavior.
>
> I have been unable to find any details of what the cause of this condition
> is, or how to prevent it having such undesirable consequences. Is this a
> known issue, or does anyone have any suggestions on how to prevent it
> happening again?
>
> OS: RHEL 5.9
> OpenSSL version: 1.0.0e
> Apache httpd version: 2.2.21
> Apache configure options used:
> ./configure --with-mpm=worker --with-included-apr \
> --enable-static-support --enable-mods-shared=most \
> --enable-proxy=shared --enable-proxy-connect=shared \
> --enable-proxy-ftp=shared --enable-proxy-http=shared \
> --enable-proxy-ajp=shared --enable-proxy-balancer=shared \
> --enable-deflate --with-z=${PREFIX} \
> --enable-ssl --with-ssl=${PREFIX} \
> --prefix=${PREFIX}
>
> SSL related configuration options:
> SSLEngine on
> SSLSessionCache"shmcb:/path/to/ssl_scache(512000)"
> SSLSessionCacheTimeout 300
> SSLMutex sem
>
Use "SSLMutex sysvsem" instead.
> SSLProtocol all -SSLv2
> SSLCipherSuite
> ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:-eNULL:-NULL
>
>
> Regards,
>
>
> Stu Tomlinson.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
