Mailing List Archive

problem at Cardiff is back
The SunOs machine www.cm.cf.ac.uk has the same problem I noticed
before.. it's running with MinSpareServers and isn't spawning
children to replace them

I installed 0.8.7 yesterday.

-=-=-=-=
od -h /tmp/htstatus.a00156
0000000 0000 1364 0200 3290 0000 1375 0200 3290
0000020 0000 1399 0100 3290 0000 13d0 0100 3290
0000040 0000 021c 0200 3290 0000 00ad 0200 3290
0000060 0000 00cb 0200 3290 0000 00cd 0200 3290
0000100 0000 00d1 0200 3290
0000110


ls -l /tmp/htstatus.a00156
-rw-rw-rw- 1 root 72 Aug 6 23:05 /tmp/htstatus.a00156


Hmm, that's small. It used to be 1200 bytes.

I don't think anyone has access to the machine to do any deliberate
damage to the scoreboard file.


-=-=-=-=-=
ServerName www.cm.cf.ac.uk
MinSpareServers 4
MaxSpareServers 17
MaxClients 50
MaxRequestsPerChild 60
-=-=-=-=-=


The nightly cron will perform a restart in about an hour.
If anyone (Rob T?) has any suggestions or ideas where to look
for clues, speak now. Last time a SIGHUP cleared the problem.

n.b. I don't have root access, so diagnositics may be limited.


There's been 1 SIGHUP since the machine was rebooted yesterday.


rob
Re: problem at Cardiff is back [ In reply to ]
> There's been 1 SIGHUP since the machine was rebooted yesterday.

make that 0. No restarts since apache was started.
Re: problem at Cardiff is back [ In reply to ]
More info that might help...

ps -lax | grep " 156 "
80488001 0 156 1 0 5 0 116 260 child S ? 0:02 /mnt60/apach
488001 128 5486 156 1 1 0 200 476 socket S ? 0:00 /mnt60/apach
488000 128 5504 156 0 1 0 212 0 socket IW ? 0:00 /mnt60/apach
488001 128 5518 156 4 1 0 236 484 socket S ? 0:00 /mnt60/apach
488001 128 5534 156 9 1 0 224 528 socket S ? 0:00 /mnt60/apach


Does that mean the parent is waiting on a child ? - it's state
doesn't change at all.

It suggests that the parent is stuck waiting for a child that no
longer exists.



rob
Re: problem at Cardiff is back [ In reply to ]
> By far the best thing would be to attach to the root process and
> figure out what it thinks it's doing; failing that, to gcore() it and
> inspect the core dump.

I don't have root access.

> The weird thing is that nothing ought to truncate the scoreboard file
> --- the only explanation that comes immediately to mind is that some
> other cron job might be cleaning out /tmp, and the scoreboard file gets
> mashed in the process. Is this possible?

Maybe, but I've looked at the cron entries for the userids that could
be doing it, and there's nothing there.
Re: problem at Cardiff is back [ In reply to ]
By far the best thing would be to attach to the root process and
figure out what it thinks it's doing; failing that, to gcore() it and
inspect the core dump.

The weird thing is that nothing ought to truncate the scoreboard file
--- the only explanation that comes immediately to mind is that some
other cron job might be cleaning out /tmp, and the scoreboard file gets
mashed in the process. Is this possible?

rst
Re: problem at Cardiff is back [ In reply to ]
That's normal --- the root process spends almost all of its time in
wait() [and it most certainly does still have child processes running].
Read the source code for details...

rst
Re: problem at Cardiff is back [ In reply to ]
> The weird thing is that nothing ought to truncate the scoreboard file
> --- the only explanation that comes immediately to mind is that some
> other cron job might be cleaning out /tmp, and the scoreboard file gets
> mashed in the process. Is this possible?

Maybe, but I've looked at the cron entries for the userids that could
be doing it, and there's nothing there.

Hmmm... and no one might have done it manually (in the name of
housekeeping), I take it...

rst
Re: problem at Cardiff is back [ In reply to ]
In reply to Andrew Wilson who said
>
> [/tmp/htwhatever.nnnn getting munged]
> > Hmmm... and no one might have done it manually (in the name of
> > housekeeping), I take it...
> >
> > rst
>
> Couldn't the scoreboard be kept in SERVER_ROOT/logs/ or somewhere
> less likely to get bombed by random clean-up code? I quite like the
> idea of having all the logfiles and conf stuff in the same area.
> Using /tmp for storing status of long running processes grates a bit
> for me.
>

Uhh, yeah. it's actually pretty bogus to do that. /tmp is for
volatile, short term use and sys admins generally don't setup their
systems to ensure that /tmp always has free space. That's
what /var is for.

If /tmp fills up apache is screwed. For vi and other apps that use
/tmp it wouldn't be a problem since a temporary lack of resources
wouldn't be just a temporary problem and since long running processes
shouldn't use /tmp space should get freed up quite regularly.

I'd agree with Andy and suggest the logs directory be used since I like
the idea of apache being self-contained.

--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
Re: problem at Cardiff is back [ In reply to ]
Date: Mon, 7 Aug 95 10:23:21 BST
From: Andrew Wilson <andrew@www.elsevier.co.uk>
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

[/tmp/htwhatever.nnnn getting munged]
> Hmmm... and no one might have done it manually (in the name of
> housekeeping), I take it...
>
> rst

Couldn't the scoreboard be kept in SERVER_ROOT/logs/ or somewhere
less likely to get bombed by random clean-up code? I quite like the
idea of having all the logfiles and conf stuff in the same area.
Using /tmp for storing status of long running processes grates a bit
for me.

I think I first suggested this a few days ago, when people were
flaming about security problems with people messing around with the
scoreboard. It's probably a good idea. I just don't want to hold up
getting something out the door for it...

rst
Re: problem at Cardiff is back [ In reply to ]
[/tmp/htwhatever.nnnn getting munged]
> Hmmm... and no one might have done it manually (in the name of
> housekeeping), I take it...
>
> rst

Couldn't the scoreboard be kept in SERVER_ROOT/logs/ or somewhere
less likely to get bombed by random clean-up code? I quite like the
idea of having all the logfiles and conf stuff in the same area.
Using /tmp for storing status of long running processes grates a bit
for me.

Ay.