[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 62277] mod_slotmem_shm is causing error in apache2.4.33 loading


--- Comment #33 from Rainer Jung <rainer.jung@xxxxxxxxxxx> ---
Hi Yann,

in addition to the file descriptor ulimit I also had to increase the number of
shared memory identifiers "project.max-shm-ids" from the default of 256 (I
chose 10000).

Running the tool with a fresh work firectory named "work" and "--path work" I

0 collision(s) for 3990/3990 files

BUT: using no "--path" and thus using /tmp I got:

shmget: File exists
0 collision(s) for 1425/3990 files

and the number 1425 varies by test run.

Underneath /tmp I always get no collisions but "shmget: File exists" using
default settings as well as with a custom sub directory. On other local or NFS
mounted directories, I do not get them. Even if I check for collisions directly
after the shmget error, I do not get such. But I had to adjust the
check_collisions argument from "i" to "i-1" (otherwise it segfaulted when
shmget threw an error).

Concerning "shmget: File exists" from the Solaris man page:

     EEXIST          A shared memory identifier  exists  for  key
                     but      both     (shmflg&IPC_CREAT)     and
                     (shmflg&IPC_EXCL) are true.

and looking at the ftok man page:

     Since the ftok() function returns a value based  on  the  id
     given  and  the file serial number of the file named by path
     in a type that is no longer large enough to  hold  all  file
     serial  numbers, it may return the same key for paths naming
     different files on large filesystems.

... and ...

     Another way to compose keys is to include the project ID  in
     the  most  significant byte and to use the remaining portion
     as a sequence number. There are  many  other  ways  to  form
     keys,  but  it  is necessary for each system to define stan-
     dards for forming them. If some standard is not adhered  to,
     it  will be possible for unrelated processes to unintention-
     ally interfere with each other's operation. It is still pos-
     sible  to interfere intentionally. Therefore, it is strongly
     suggested that the most significant byte of a  key  in  some
     sense refer to a project so that keys do not conflict across
     a given system.

I also compiled as a 64 bit binary but got the same results.

Here's an example for two identical keys generated by ftok:

ftok 81/3990 for /tmp/slotmem-shm-p98b37289_ir.shm and -544118222 is 838870549
ftok 168/3990 for /tmp/slotmem-shm-p5750b6d1_jra.shm and 1374409266 is

In sys/types.h there's a part

 * POSIX and XOPEN Declarations
typedef int     key_t;                  /* IPC key type         */



You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx