https://issues.apache.org/bugzilla/show_bug.cgi?id=55449
--- Comment #5 from Andre W. <[email protected]> --- Hello Jim, okay, let's explain it a little bit more in detail, what is meant by different instances. Currently, we run multiple different apache http servers (up 100 or more single instances) on an single server instance. To realize this, each apache server is executed by a single user inside a single workspace were only this user and root has access, also each server as a well defined port range, which he is able to use. i.e. the main config is like this: APACHE_USER="<project_user>" #the user httpd runs with APACHE_INSTANCE="<project_name>" APACHE_PROJ="<project_path>" #will be handed over as startparameter ServerRoot ${APACHE_INSTROOT} #Installationpath of the apache exectuble DefaultRuntimeDir /var/tmp/apache_${APACHE_INSTANCE} PidFile ${DEFAULTRUNTIMEDIR}/httpd.pid As you can see we already set a different DefaultRuntimeDir, because in previous cases we had the problem of the collision of the different *.shm files. But actually we don't have collisions on the *.shm files, we have collisions inside the shared memory slots of the unix system. This failure occours from my point of investigation, through the generation of an already existing key inside the shared memory register of the unix system (see also my last post). It is true that it is not able to minimize these collisons to zero (the definition of ftok(3) tells nearly the same, see below), but with further investigation to generate a more unique key it should be able to reduce these collisons (point of investigation could be the projid, which is always set to 1, maybe a possibility could be to use the port number, or give the user the ability to configure this variable inside httpd.conf or via start parameter). I think the collisions are coming up because of the variance of the hash value ftok is called with is two low, so that an internal recalculation inside ftok leads to the collision (This is also really well described here https://issues.apache.org/bugzilla/show_bug.cgi?id=53996). Hopefully that helps, Best regards, André 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. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
