httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mark <m...@node.to>
Subject apr_shm_create / attach behaviour
Date Sat, 13 Mar 2004 23:27:55 GMT

Summary:
apr_shm_create returns APR_SUCCESS when it should be APR_EEXIST
in certain circumstances in my module. I'm not sure this is a bug, a known
design, or what. Hope some of you developers will have seen this before.

Environment:
httpd-2.0.48, apr 0.9.5, on freebsd 5.2.1 and solaris 2.7
in context: forked processes (either prefork mpm, or worker
mpm when additional server/threadgroup is spawned).

Detail:

My child_init hook has logic like this:

if (shm create result == success)
{
	/* first child wins here, all others should attach */
	/* log created shm */
}
else if (result == exists)
{
	shm attach
	/* log attached shm */
}
else
{
	/* log error */
}

This is modeled after some other modules.
A per-process shm seg ptr is passed along with a shm path held in the
"conf" (module specific) structure. Based on my logs the path is getting
there correctly.

On FreeBSD, what happens is this: under heavy load, after many
additional child spawns, one of them will spawn and return "APR_SUCCESS"
for apr_shm_create. This segment lacks an ipc key, and is not mapped to
the real, existing segment at the specified path. Other children still
alive are still attached to the correct segment. New children spawned
after the bogusly created one attach to the keyless incorrect segment.

On Solaris, any child spawned after the initial spawn count indicated by
"StartServers" has this problem, only "ipcs -a" doesn't even show a null
key segment.

Any thoughts?
Is there some resetting or reforking of the root httpd proc under certain
condtions, prior to the launching of new children?

Thanks for any help,
--mark wolgemuth

  mark@node.to http://node.to/~mark 7123 3F7B 10EC 7122 2F8B
  http://node.to/keys/mark.asc         B474 B09D 6ED7 3FB0 09E8


Mime
View raw message