You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Randy Terbush <ra...@zyzzyva.com> on 1997/01/22 19:03:46 UTC
[PATCH] locating mutex lockfile in PID file directory
I have the following patch that attempts to put the mutex lock
file in the same directory as the PID file. I've attempted to
test this on FreeBSD by forcing USE_FCNTL_ACCEPT_MUTEX (or whatever)
and it does not seem to work. I don't see why the children should
not be able to get a lock on this file with one execption and
that is permissions. We are opening as root WR_ONLY with 644 perms.
How could any of the child processes lock this descriptor? I'm
assuming they would need to be able to write the file in order to
lock it. ??
Comments. If you can test this on a platform that actually uses
this code, it would be helpful.
Index: http_main.c
===================================================================
RCS file: /export/home/cvs/apache/src/http_main.c,v
retrieving revision 1.108
diff -c -r1.108 http_main.c
*** http_main.c 1997/01/20 04:28:08 1.108
--- http_main.c 1997/01/20 05:29:02
***************
*** 192,207 ****
*/
void
accept_mutex_init(pool *p)
! {
char lock_fname[256];
! #ifdef __MACHTEN__
! strncpy(lock_fname, "/var/tmp/htlock.XXXXXX", sizeof(lock_fname)-1);
! #else
! strncpy(lock_fname, "/usr/tmp/htlock.XXXXXX", sizeof(lock_fname)-1);
! #endif
! lock_fname[sizeof(lock_fname)-1] = '\0';
!
if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
{
fprintf (stderr, "Cannot assign name to lock file!\n");
--- 192,204 ----
*/
void
accept_mutex_init(pool *p)
! {
char lock_fname[256];
! ap_snprintf(lock_fname, (sizeof(lock_fname)-1), "%s", pid_fname);
! lock_fname[(rind(lock_fname, '/')) + 1] = '\0';
! strcat(lock_fname, "htlock.XXXXXX\0");
!
if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
{
fprintf (stderr, "Cannot assign name to lock file!\n");
***************
*** 254,261 ****
{
char lock_fname[256];
! strncpy(lock_fname, "/usr/tmp/htlock.XXXXXX", sizeof(lock_fname)-1);
! lock_fname[sizeof(lock_fname)-1] = '\0';
if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
{
--- 251,259 ----
{
char lock_fname[256];
! ap_snprintf(lock_fname, (sizeof(lock_fname)-1), "%s", pid_fname);
! lock_fname[(rind(lock_fname, '/')) + 1] = '\0';
! strcat(lock_fname, "htlock.XXXXXX\0");
if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
{
Re: [PATCH] locating mutex lockfile in PID file directory
Posted by Marc Slemko <ma...@valis.worldgate.com>.
On Wed, 22 Jan 1997, Randy Terbush wrote:
>
> I have the following patch that attempts to put the mutex lock
> file in the same directory as the PID file. I've attempted to
> test this on FreeBSD by forcing USE_FCNTL_ACCEPT_MUTEX (or whatever)
> and it does not seem to work. I don't see why the children should
> not be able to get a lock on this file with one execption and
> that is permissions. We are opening as root WR_ONLY with 644 perms.
> How could any of the child processes lock this descriptor? I'm
> assuming they would need to be able to write the file in order to
> lock it. ??
But doing things the current way we don't have write access to the
file either, right? The difference is that currently we have write
access to the directory while with this we don't.
What errno is it giving you?
Re: [PATCH] locating mutex lockfile in PID file directory
Posted by Marc Slemko <ma...@znep.com>.
On Wed, 22 Jan 1997, Randy Terbush wrote:
>
> I have the following patch that attempts to put the mutex lock
> file in the same directory as the PID file. I've attempted to
> test this on FreeBSD by forcing USE_FCNTL_ACCEPT_MUTEX (or whatever)
> and it does not seem to work. I don't see why the children should
> not be able to get a lock on this file with one execption and
> that is permissions. We are opening as root WR_ONLY with 644 perms.
> How could any of the child processes lock this descriptor? I'm
> assuming they would need to be able to write the file in order to
> lock it. ??
Take a look at struct flock in BSD. Note that although the members appear
similar enough on different platforms, the orders are different. We
initialize the structures like:
static struct flock lock_it = { F_WRLCK, 0, 0, 0 };
That gives a l_start of F_WRLCK, a length, pid, and type of 0 and no
whence field on BSD. No wonder it doesn't like it. I think you will find
the same thing happens under FreeBSD even without your patches.
It appears to work fine in a little test program once I did the
initialization of the struct flock by member name not by order.
>
> Comments. If you can test this on a platform that actually uses
> this code, it would be helpful.
>
> Index: http_main.c
> ===================================================================
> RCS file: /export/home/cvs/apache/src/http_main.c,v
> retrieving revision 1.108
> diff -c -r1.108 http_main.c
> *** http_main.c 1997/01/20 04:28:08 1.108
> --- http_main.c 1997/01/20 05:29:02
> ***************
> *** 192,207 ****
> */
> void
> accept_mutex_init(pool *p)
> ! {
> char lock_fname[256];
>
> ! #ifdef __MACHTEN__
> ! strncpy(lock_fname, "/var/tmp/htlock.XXXXXX", sizeof(lock_fname)-1);
> ! #else
> ! strncpy(lock_fname, "/usr/tmp/htlock.XXXXXX", sizeof(lock_fname)-1);
> ! #endif
> ! lock_fname[sizeof(lock_fname)-1] = '\0';
> !
> if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
> {
> fprintf (stderr, "Cannot assign name to lock file!\n");
> --- 192,204 ----
> */
> void
> accept_mutex_init(pool *p)
> ! {
> char lock_fname[256];
>
> ! ap_snprintf(lock_fname, (sizeof(lock_fname)-1), "%s", pid_fname);
> ! lock_fname[(rind(lock_fname, '/')) + 1] = '\0';
> ! strcat(lock_fname, "htlock.XXXXXX\0");
> !
> if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
> {
> fprintf (stderr, "Cannot assign name to lock file!\n");
> ***************
> *** 254,261 ****
> {
> char lock_fname[256];
>
> ! strncpy(lock_fname, "/usr/tmp/htlock.XXXXXX", sizeof(lock_fname)-1);
> ! lock_fname[sizeof(lock_fname)-1] = '\0';
>
> if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
> {
> --- 251,259 ----
> {
> char lock_fname[256];
>
> ! ap_snprintf(lock_fname, (sizeof(lock_fname)-1), "%s", pid_fname);
> ! lock_fname[(rind(lock_fname, '/')) + 1] = '\0';
> ! strcat(lock_fname, "htlock.XXXXXX\0");
>
> if (mktemp(lock_fname) == NULL || lock_fname[0] == '\0')
> {
>
>