Re: pkg/50990: apache-2.2.31nb2 is not working well on netbsd-7

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR pkg/50990; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/50990: apache-2.2.31nb2 is not working well on netbsd-7
Date: Thu, 24 Mar 2016 21:57:11 +0100

 After noticing that a regular "chown()" is renamed to posix_chown,
 I found the failing source:
 
 In mod_python.c::init_mutexes we find:
 
 #if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
         char fname[255];
         /* XXX What happens if len(mutex_dir) > 255 - len(mpmtx%d%d)? */
         snprintf(fname, 255, "%s/mpmtx%d%d", mutex_dir, glb->parent_pid, n);
 #else
         char *fname = NULL;
 #endif
         rc = apr_global_mutex_create(&mutex[n], fname, APR_LOCK_DEFAULT,   
                                      p);
 
 
 So here the magic filename is created, and then apr_global_mutex_create
 goes to a shmget() instead of using something in the file system.
 
 However, if the mutex creation works, we run into this:
 
 #if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
 #if AP_MODULE_MAGIC_AT_LEAST(20081201,0)
             ap_unixd_set_global_mutex_perms(mutex[n]);
 #else
             if (!geteuid()) {
                 chown(fname, unixd_config.user_id, -1);
                 unixd_set_global_mutex_perms(mutex[n]);
             }
 #endif
 #endif
 
 and execute the #else (20081201 is not in apache 2.2). The failure to chown
 is not fatal here.
 
 So it all boils down to 
 
  14631      1 httpd    CALL  semget(0,1,0x380)
  14631      1 httpd    RET   semget -1 errno 28 No space left on device
 
 and the man page says:
 
      [ENOSPC]           A new set of semaphores could not be created because
                         the system limit for the number of semaphores or the
                         number of semaphore sets has been reached.
 
 We are leaking semaphores somewhere but cleaning them up on shutdown
 of apache?
 
 Martin