You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@remulak.net> on 2002/04/01 18:52:10 UTC

2.0.34 - apr_lock_create fails on daedalus

2.0.34 built cleanly on daedalus.  But when I tried to start it, I got:

[gregames@daedalus apache2.0.34]$ tail logs/www/error_log
[Mon Apr 01 08:36:31 2002] [notice] suEXEC mechanism enabled (wrapper:
/usr/local/apache2.0.34/bin/suexec)
[Mon Apr 01 08:36:31 2002] [crit] (28)No space left on device: mod_rewrite:
could not create rewrite_log_lock
Configuration Failed
 
The msg appears to be bogus; we have space.  Here's the code:

    /* create the rewriting lockfiles in the parent */
    if ((rv = apr_lock_create(&rewrite_log_lock, APR_MUTEX, APR_LOCKALL,
                              APR_LOCK_DEFAULT, NULL, p)) != APR_SUCCESS) {
        ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s,
                     "mod_rewrite: could not create rewrite_log_lock");
        return HTTP_INTERNAL_SERVER_ERROR;

I'll gdb this after lunch.  If you have any thoughts about what may be causing
this, please speak up.

Greg

Re: 2.0.34 - apr_lock_create fails on daedalus

Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:

> With apr_hints.m4 patched to use FLOCK on FreeBSD, apr.h looks right.  But when
> I start it, I get:

> [Mon Apr 01 10:10:02 2002] [emerg] (9)Bad file descriptor: Couldn't initialize
> cross-process lock in child

> ...and the parent bails, leaving the children orphaned.  I'll try FCNTL next.

It's up & running on port 8092 using FCNTL.

Greg

Re: 2.0.34 - apr_lock_create fails on daedalus

Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:

> > 2) validate that SysV sem is the proper mutex mechanism we should be
> >    using by default on FreeBSD
> 
> Probably not.  apache-1.3's ap_config.h defines HAVE_FLOCK_SERIALIZED_ACCEPT for
> FreeBSD, but apr_hint.m4 doesn't have similar logic in 2.0.  I'll patch that,
> and give it a shot.

With apr_hints.m4 patched to use FLOCK on FreeBSD, apr.h looks right.  But when
I start it, I get:

[Mon Apr 01 10:10:02 2002] [emerg] (9)Bad file descriptor: Couldn't initialize
cross-process lock in child
[Mon Apr 01 10:10:02 2002] [emerg] (9)Bad file descriptor: Couldn't initialize
cross-process lock in child
[Mon Apr 01 10:10:02 2002] [notice] Apache/2.0.34 (Unix) configured -- resuming
normal operations
[Mon Apr 01 10:10:02 2002] [alert] Child 74540 returned a Fatal error...
Apache is exiting!

...and the parent bails, leaving the children orphaned.  I'll try FCNTL next.  

Greg

Re: 2.0.34 - apr_lock_create fails on daedalus

Posted by Greg Ames <gr...@remulak.net>.
Jeff Trawick wrote:

> 1) see what syscall failed and how to make it stop failing (OS tuning
>    perhaps?)

daedulus's truss doesn't have an option to follow fork()s :(  But I think I'll
switch to Plan B anyway...see below.

> 2) validate that SysV sem is the proper mutex mechanism we should be
>    using by default on FreeBSD

Probably not.  apache-1.3's ap_config.h defines HAVE_FLOCK_SERIALIZED_ACCEPT for
FreeBSD, but apr_hint.m4 doesn't have similar logic in 2.0.  I'll patch that,
and give it a shot.

Greg

Re: 2.0.34 - apr_lock_create fails on daedalus

Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Ames <gr...@remulak.net> writes:

> 2.0.34 built cleanly on daedalus.  But when I tried to start it, I got:
> 
> [gregames@daedalus apache2.0.34]$ tail logs/www/error_log
> [Mon Apr 01 08:36:31 2002] [notice] suEXEC mechanism enabled (wrapper:
> /usr/local/apache2.0.34/bin/suexec)
> [Mon Apr 01 08:36:31 2002] [crit] (28)No space left on device: mod_rewrite:
> could not create rewrite_log_lock
> Configuration Failed
>  
> The msg appears to be bogus; we have space.  Here's the code:

ENOSPC is one of the possible errnos returned by SysV semaphore
operations.  You could do a truss and see which syscall is actually
returning ENOSPC.

I think JimJag changed the APR rules for picking the default mutex
recently.  That could have resulted in this change in behavior.

If it were me I'd take two asynch approaches:

1) see what syscall failed and how to make it stop failing (OS tuning
   perhaps?)

2) validate that SysV sem is the proper mutex mechanism we should be
   using by default on FreeBSD

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...