[PATCH] apr_shm_create/shmget/fopen flags

[Joe Orton <jo...@redhat.com>]

For the implementation of name-based apr_shm_create using shmget (i.e.
the filename != NULL case), I've got two questions:

1) why is APR_EXCL passed to the apr_file_open call?  This is annoying
for Apache since if the server crashes, you have to remove the shmem
segment *and* the filename before restarting.  Patch below OK? 

2) why is the file used to store the segment size, rather than using the
shm_segsz member of the shmid_ds structure?

joe

Index: unix/shm.c
===================================================================
RCS file: /home/cvs/apr/shmem/unix/shm.c,v
retrieving revision 1.19
diff -u -r1.19 shm.c
--- unix/shm.c	20 Nov 2002 03:50:22 -0000	1.19
+++ unix/shm.c	13 Dec 2002 17:17:41 -0000
@@ -361,7 +361,7 @@
 
         /* FIXME: APR_OS_DEFAULT is too permissive, switch to 600 I think. */
         status = apr_file_open(&file, filename, 
-                               APR_WRITE | APR_CREATE | APR_EXCL,
+                               APR_WRITE | APR_CREATE | APR_TRUNCATE,
                                APR_OS_DEFAULT, pool);
         if (status != APR_SUCCESS) {
             return status;

Re: [PATCH] apr_shm_create/shmget/fopen flags

[Jim Jagielski <ji...@jaguNET.com>]

At 5:20 PM +0000 12/13/02, Joe Orton wrote:
>For the implementation of name-based apr_shm_create using shmget (i.e.
>the filename != NULL case), I've got two questions:
>
>1) why is APR_EXCL passed to the apr_file_open call?  This is annoying
>for Apache since if the server crashes, you have to remove the shmem
>segment *and* the filename before restarting.  Patch below OK?
>

Basically, it's a protection mechanism. Since each segment is
backed up with a file, you want (and need) to ensure that APR
has sole access/control over that file, hence the EXCL setting.

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

Re: [PATCH] apr_shm_create/shmget/fopen flags

[Joe Orton <jo...@manyfish.co.uk>]

On Fri, Dec 13, 2002 at 09:41:51AM -0800, Aaron Bannert wrote:
> If your application is sure that the segment is not in use, then remove
> the file.

OK, fair enough, thanks.

> >2) why is the file used to store the segment size, rather than using 
> >the
> >shm_segsz member of the shmid_ds structure?
> 
> I assume you're talking about APR_USE_SHMEM_SHMGET and not SHMGET_ANON?

Yup, name-based as I said...

> I can't remember why I did that, but I think there was a reason. It
> might have had to do with page-alignment of the size, or the need for
> the actual requested size rather than the OS's returned size.

shmget is defined (by Single Unix, the Solaris and Linux man pages say
the same) specifically to store the value of the size parameter in
shm_segsz - is there a platform where this isn't true that you know of?
(it's a bit clumsy and adds more error paths so it would be nice to
remove if possible)

Regards,

joe

Re: [PATCH] apr_shm_create/shmget/fopen flags

[Aaron Bannert <aa...@clove.org>]

On Friday, December 13, 2002, at 09:20  AM, Joe Orton wrote:

> For the implementation of name-based apr_shm_create using shmget (i.e.
> the filename != NULL case), I've got two questions:
>
> 1) why is APR_EXCL passed to the apr_file_open call?  This is annoying
> for Apache since if the server crashes, you have to remove the shmem
> segment *and* the filename before restarting.  Patch below OK?

The existance of the file can only mean that the application doesn't
know what state that shmem segment is in, and must deal with that before
trying to recreate the segment. For example, if you accidently started
Apache a second time, you wouldn't want it to trounce on the previous
instance's shmem file.

If your application is sure that the segment is not in use, then remove
the file.

> 2) why is the file used to store the segment size, rather than using 
> the
> shm_segsz member of the shmid_ds structure?

I assume you're talking about APR_USE_SHMEM_SHMGET and not SHMGET_ANON?
I can't remember why I did that, but I think there was a reason. It
might have had to do with page-alignment of the size, or the need for
the actual requested size rather than the OS's returned size.

-aaron