apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 53996] New: shmget fails on duplicate ftok
Date Fri, 12 Oct 2012 13:06:13 GMT

          Priority: P2
            Bug ID: 53996
          Assignee: bugs@apr.apache.org
           Summary: shmget fails on duplicate ftok
          Severity: major
    Classification: Unclassified
                OS: Linux
          Reporter: Dick.Snippe@tech.omroep.nl
          Hardware: PC
            Status: NEW
           Version: 1.4.6
         Component: APR
           Product: APR

One of our 2.4.3 apache stopped working after a graceful restart, leaving this
error message:

[Fri Oct 12 00:00:01.782399 2012] [auth_digest:notice] [pid 15960:tid
140576559888112] AH01757: generating secret for digest authentication ...
[Fri Oct 12 00:00:01.782459 2012] [auth_digest:error] [pid 15960:tid
140576559888112] (17)File exists: AH01762: Failed to create shared memory
segment on file /e/fp/smooto2a/scratch/authdigest_shm.15960
[Fri Oct 12 00:00:01.782482 2012] [auth_digest:error] [pid 15960:tid
140576559888112] (17)File exists: AH01760: failed to initialize shm - all
nonce-count checking, one-time nonces, and MD5-sess algorithm disabled
[Fri Oct 12 00:00:01.782487 2012] [:emerg] [pid 15960:tid 140576559888112]
AH00020: Configuration Failed, exiting

In our case we are running multiple apache instances on the same server and it
turned out that 2 instances have a ftok() collision on their authdigest_shm

The current shared memory segment belongs to the "smooti2a" instance and when
"smooto2a" tried to start it failed with:
17725 open("/e/fp/smooto2a/scratch/authdigest_shm.17725",
O_WRONLY|O_CREAT|O_EXCL|0x80000, 0666) = 7
17725 stat("/e/fp/smooto2a/scratch/authdigest_shm.17725",
{st_mode=S_IFREG|0664, st_size=0, ...}) = 0
17725 shmget(0x10600aa, 1000, IPC_CREAT|IPC_EXCL|0600) = -1 EEXIST (File

I wrote a small C program to display the ftok on an arbitrary file and ran that
on both authdigest_shm files:
$ ftok /e/fp/smooto2a/scratch/authdigest_shm.17725
/e/fp/smooto2a/scratch/authdigest_shm.17725 10600aa
/e/fp/smooti2a/scratch/authdigest_shm.13024 10600aa

The inode numbers of both files happen to be very similar:
$ ls -i  /e/fp/smooto2a/scratch/authdigest_shm.17725
 8388778 /e/fp/smooti2a/scratch/authdigest_shm.13024
16777386 /e/fp/smooto2a/scratch/authdigest_shm.17725

This can be seen when the inode numbers are displayed in hex:
$ printf "%07x\n%07x\n" 8388778 16777386

The similar inode numbers are possibly caused by our choice of filesystem (xfs)

So it would seem that the warning in the ftok(3) manpage applies:
       Of course no guarantee can be given that the resulting key_t is unique.
       Typically, a best effort attempt combines the given proj_id  byte,  the
       lower  16 bits of the i-node number, and the lower 8 bits of the device
       number into a 32-bit result.  Collisions may easily happen, for example
       between files on /dev/hda1 and files on /dev/sda1.

When browsing through the apr code (shmem/unix/shm.c) it appears that
shmkeys are always generated with proj_id == 1:

        /* ftok() (on solaris at least) requires that the file actually
         * exist before calling ftok(). */
        shmkey = ftok(filename, 1);
        if (shmkey == (key_t)-1) {
            return errno;

        if ((new_m->shmid = shmget(shmkey, new_m->realsize,
                                   SHM_R | SHM_W | IPC_CREAT | IPC_EXCL)) < 0)
            return errno;

Perhaps ftok could be made to iterate over a number of proj_id's and use the
first proj_id where shmget succeeds?
However, that would require addinional logic in the apr_shm_remove function,
because it also uses ftok to calculate the shmkey to remove.
What would be needed is that the shmkey is stored somewhere when it is created
and the stored value of shmkey is used when the time has arrived to destroy
the shared memory segment.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message