You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/01/01 04:41:26 UTC

latest redhat rpm of apache

(finally grabbed the utility from the rpm tools directory to strip the
header junk off a .rpm, modified it to make it actually work, ran it,
ungzipped, uncpioed, and looked through the latest package...



	 /* Default administrator's address */
	-#define DEFAULT_ADMIN "[no address given]"
	+#define DEFAULT_ADMIN "root@localhost"

why!?!?  why replace a valid no address with a bogus address?  (ok...
the above isn't in the most recent one anymore, now they just do:

	-ServerAdmin you@your.address
	+ServerAdmin root@localhost

which I'm not sure helps anything...


The latest Redhat 1.2 package still uses killall for log rotation:

	/var/log/httpd/access_log {
	    postrotate
		/usr/bin/killall -HUP httpd
	    endscript
	}

	/var/log/httpd/agent_log {
	    postrotate
		/usr/bin/killall -HUP httpd
	    endscript
	}

	/var/log/httpd/error_log {
	    postrotate
		/usr/bin/killall -HUP httpd
	    endscript
	}

	/var/log/httpd/referer_log {
	    postrotate
		/usr/bin/killall -HUP httpd
	    endscript
	}

Sigh.

And for their httpd.init script they do:

  stop)
        echo -n "Shutting down http: "
        killproc httpd
        echo
        rm -f /var/lock/subsys/httpd
        ;;

(no idea what killproc does...)

but restart is the silly:

  restart)
        $0 stop
        $0 start
        ;;




Re: latest redhat rpm of apache

Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Jan 01, 1998 at 09:45:17AM -0700, Marc Slemko wrote:
> On Thu, 1 Jan 1998, Manoj Kasichainula wrote:
> > I've mentioned this to them. In my RPMs, I've always eliminated the
> > first three killall's, and I'm planning to change the fourth to a USR1
> > signal.
> 
> Does it compress the logs at all?

Hmmm. It doesn't by default, but it can, through an option in the
logrotate config files. I guess that I should keep the signal as HUP
then.  I don't know what will happen to logrotate if it is kept
waiting for a sleep command, so I'd rather not use that to wait for
the logs.

> > > (no idea what killproc does...)
> > 
> > The same thing as killall, but killproc is guaranteed to be available
> > in rc.d scripts, while killall may never be available.
> 
> And what signal does it use?  TERM?

TERM, then KILL eventually (by default). Here's the relevant snippet
of code:

            # TERM first, then KILL if not dead
            kill -TERM $pid
            usleep 100000
            dead=`ps aux | awk '{print $2}' | grep $pid`
            if [ "$dead" != "" ]; then
                sleep 3
                kill -KILL $pid
            fi

Could be improved a bit, but it should be okay. FYI, killall uses TERM
by default.

> > > but restart is the silly:
> > > 
> > >   restart)
> > >         $0 stop
> > >         $0 start
> > >         ;;
> > 
> > Fixing this too. Will use -USR1.
> 
> You may want to consider -HUP because understanding what -USR1 does and
> doesn't do can take more brainpower than HUP does.  If people want to use
> it for logfile rotations of their own, etc. -USR1 could mess them up.

Okay. Will do. One thing I need to find out though is what semantics
restart is supposed to have, i.e. whether it's supposed to start the
server if it hasn't been started or if it is unspecified.

I'm kind of wary about throwing around a lot of SIGHUPs, since each
one kills off all connections. But, anyone running a really important
web server is probably not using an RPM anyway, or at least will edit
scripts.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Would you die for The One?"
"I wouldn't get pizza for the one. That ain't my job." - J.M. Straczynski

Re: latest redhat rpm of apache

Posted by Dean Gaudet <dg...@arctic.org>.
I didn't state all that I want... I want the ability to seamlessly replace
the httpd binary.  One way is to use the listenwrap technique I posted a
while ago; another way is to have the children close out all of the
listening sockets when they receive a USR1. 

Dean

On Sun, 4 Jan 1998, Paul Sutton wrote:

> On Sat, 3 Jan 1998, Dean Gaudet wrote:
> > I really dislike HUP.  I'd love "graceful shutdown" as well. 
> 
> Win32 now uses graceful shutdown. 
> 
> //pcs
> 
> 
> 


Re: latest redhat rpm of apache

Posted by Paul Sutton <pa...@awe.com>.
On Sat, 3 Jan 1998, Dean Gaudet wrote:
> I really dislike HUP.  I'd love "graceful shutdown" as well. 

Win32 now uses graceful shutdown. 

//pcs



Re: latest redhat rpm of apache

Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 3 Jan 1998, Ben Laurie wrote:

> Ah! I'm talking about "how do you reset Apache (HUP or USR1) and know
> when the reset has finished?". Isn't that what this was all about in the
> first place?

That's one of the topics of discussion, yup :)  The other was how to kill
apache.

For log rotation I have two favs:

- reliable piped logs, just rename the logs and kill the logger, apache will
    restart it without a hiccough.  Ok, well, make sure your logger knows
    to close its input, and finish up cleanly.

- all children acquire a shared lock on the logs.  Rename the logs, send a
    USR1, and use the (as yet unwritten) waitlock program to acquire an
    exclusive lock, when the lock is acquired you know all the old
    children died.

I prefer the first because you know rotation will take a very short amount
of time.  In the second case if one of the children is busy sending a
bazillion Mb to a slow client the child could take a long time before
writing the one log entry. 

I really dislike HUP.  I'd love "graceful shutdown" as well. 

Oh btw, one of the concerns with piped logs is efficiency -- but it's
really just an O(1) issue I think, you can always run a half dozen piped
logs at the same time to distribute the load (and take advantage of
parallelism). 

Dean


Re: latest redhat rpm of apache

Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> 
> On Sat, 3 Jan 1998, Ben Laurie wrote:
> 
> > Dean Gaudet wrote:
> >
> > > The parent doesn't exit until after it's spent a whack of time in
> > > reclaim_child_processes() brutally killing off all the children.  So all
> > > the children have released their locks and died, then the parent releases
> > > its lock and dies.  Then waitlock is able to acquire an exclusive lock.
> >
> > Hold on. Am I losing it completely? I though the parent didn't exit at
> > all?
> 
> Maybe we're talking about separate issues.  I'm dealing with "how do you
> kill off httpd and be sure it actually completely exited?".

Ah! I'm talking about "how do you reset Apache (HUP or USR1) and know
when the reset has finished?". Isn't that what this was all about in the
first place?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: latest redhat rpm of apache

Posted by Dean Gaudet <dg...@arctic.org>.

On Sat, 3 Jan 1998, Ben Laurie wrote:

> Dean Gaudet wrote:
>
> > The parent doesn't exit until after it's spent a whack of time in
> > reclaim_child_processes() brutally killing off all the children.  So all
> > the children have released their locks and died, then the parent releases
> > its lock and dies.  Then waitlock is able to acquire an exclusive lock.
> 
> Hold on. Am I losing it completely? I though the parent didn't exit at
> all?

Maybe we're talking about separate issues.  I'm dealing with "how do you
kill off httpd and be sure it actually completely exited?".

Dean


Re: latest redhat rpm of apache

Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> 
> On Fri, 2 Jan 1998, Ben Laurie wrote:
> 
> > Dean Gaudet wrote:
> > >
> > > Actually when I mailed ewt@redhat.com about the kill -9 problem he
> > > asked me if there was any way for him to know the daemon had died.
> > > I said there wasn't and was there another daemon that behaved in a way he
> > > liked 'cause I could emulate it.  He said nope, it's a general problem,
> > > a solution would be great.  So here's my proposed solution.
> > >
> > > After setting up the pid file the parent acquires a sharable lock on it.
> > > (The parent exits if the lock fails).  Each child also child acquires
> > > a sharable lock.  flock() or fcntl() will work for this.
> > >
> > > A support utility "waitlock filename timeout" attempts to acquire an
> > > exclusive lock on filename.  Once it has acquired the exclusive lock
> > > it exits with code 0.  On any error it exits with code 1, on timeout it
> > > exits with code 2.
> >
> > Hang on - how is it going to ever acquire an exclusive lock? The parent
> > is still holding a shared lock! I presume you have a model along the
> > lines of:
> 
> The parent doesn't exit until after it's spent a whack of time in
> reclaim_child_processes() brutally killing off all the children.  So all
> the children have released their locks and died, then the parent releases
> its lock and dies.  Then waitlock is able to acquire an exclusive lock.

Hold on. Am I losing it completely? I though the parent didn't exit at
all?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: latest redhat rpm of apache

Posted by Dean Gaudet <dg...@arctic.org>.

On Fri, 2 Jan 1998, Ben Laurie wrote:

> Dean Gaudet wrote:
> > 
> > Actually when I mailed ewt@redhat.com about the kill -9 problem he
> > asked me if there was any way for him to know the daemon had died.
> > I said there wasn't and was there another daemon that behaved in a way he
> > liked 'cause I could emulate it.  He said nope, it's a general problem,
> > a solution would be great.  So here's my proposed solution.
> > 
> > After setting up the pid file the parent acquires a sharable lock on it.
> > (The parent exits if the lock fails).  Each child also child acquires
> > a sharable lock.  flock() or fcntl() will work for this.
> > 
> > A support utility "waitlock filename timeout" attempts to acquire an
> > exclusive lock on filename.  Once it has acquired the exclusive lock
> > it exits with code 0.  On any error it exits with code 1, on timeout it
> > exits with code 2.
> 
> Hang on - how is it going to ever acquire an exclusive lock? The parent
> is still holding a shared lock! I presume you have a model along the
> lines of:

The parent doesn't exit until after it's spent a whack of time in
reclaim_child_processes() brutally killing off all the children.  So all
the children have released their locks and died, then the parent releases
its lock and dies.  Then waitlock is able to acquire an exclusive lock.

Dean


Re: latest redhat rpm of apache

Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> 
> Actually when I mailed ewt@redhat.com about the kill -9 problem he
> asked me if there was any way for him to know the daemon had died.
> I said there wasn't and was there another daemon that behaved in a way he
> liked 'cause I could emulate it.  He said nope, it's a general problem,
> a solution would be great.  So here's my proposed solution.
> 
> After setting up the pid file the parent acquires a sharable lock on it.
> (The parent exits if the lock fails).  Each child also child acquires
> a sharable lock.  flock() or fcntl() will work for this.
> 
> A support utility "waitlock filename timeout" attempts to acquire an
> exclusive lock on filename.  Once it has acquired the exclusive lock
> it exits with code 0.  On any error it exits with code 1, on timeout it
> exits with code 2.

Hang on - how is it going to ever acquire an exclusive lock? The parent
is still holding a shared lock! I presume you have a model along the
lines of:

1. Launch children
2. Acquire shared lock
3. Wait for signal
4. Release shared lock
5. Go to 1

(1&2 can be swapped, of course). But even this model relies on semantics
that I'm not convinced are defined, i.e. that the exclusive lock will be
acquired as soon as it can be.

> Then shutting down the server becomes:
> 
>     kill -TERM `cat /var/run/httpd.pid`
>     waitlock /var/run/httpd.pid 600
>     exit $?
> 
> I suppose you could do kill -9, but I kinda hate doing that even in
> completely broken situations, especially in scripts.  "killall -9 httpd"
> could take out completely unrelated httpds.
> 
> There's another use for this type of locking:  kill -USR1.  If you modify
> the children to all share lock the log files, then doing a waitlock
> after a rotation attempt will let you continue when all the children
> have completed.  But this still isn't as nice in my opinion as using a
> piped logger, because the piped logger can rotate immediately.

And I don't see how this can work at all - the children will overlap, so
the locked file will never be lockless (in general).

> But I think this is a nice way to know a signal has been received and
> processed.  An alternative is to use a control interface somewhat like
> INN does -- via a unix domain socket.

Or put the generation number in a file. Increment it when all the
children have died. Poll it in your kill script.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: latest redhat rpm of apache

Posted by Dean Gaudet <dg...@arctic.org>.
Martijn Koster mentioned that you can use:

    kill -0 "`cat /var/run/httpd.pid`"

But that can succeed while there's still a child hanging around... if we
used a process group we could use:

    kill -0 "-`cat /var/run/httpd.pid`"

Well, ok, actually we already use a process group.  So this already works.

Or rather, it works for some unixes but not others I'd guess.  Either
solution has portability concerns.  Everything modern should support both. 

Dean

On Thu, 1 Jan 1998, Dean Gaudet wrote:

> Actually when I mailed ewt@redhat.com about the kill -9 problem he
> asked me if there was any way for him to know the daemon had died.
> I said there wasn't and was there another daemon that behaved in a way he
> liked 'cause I could emulate it.  He said nope, it's a general problem,
> a solution would be great.  So here's my proposed solution.
> 
> After setting up the pid file the parent acquires a sharable lock on it.
> (The parent exits if the lock fails).  Each child also child acquires
> a sharable lock.  flock() or fcntl() will work for this.
> 
> A support utility "waitlock filename timeout" attempts to acquire an
> exclusive lock on filename.  Once it has acquired the exclusive lock
> it exits with code 0.  On any error it exits with code 1, on timeout it
> exits with code 2.
> 
> Then shutting down the server becomes:
> 
>     kill -TERM `cat /var/run/httpd.pid`
>     waitlock /var/run/httpd.pid 600
>     exit $?
> 
> I suppose you could do kill -9, but I kinda hate doing that even in
> completely broken situations, especially in scripts.  "killall -9 httpd"
> could take out completely unrelated httpds.
> 
> There's another use for this type of locking:  kill -USR1.  If you modify
> the children to all share lock the log files, then doing a waitlock
> after a rotation attempt will let you continue when all the children
> have completed.  But this still isn't as nice in my opinion as using a
> piped logger, because the piped logger can rotate immediately.
> 
> But I think this is a nice way to know a signal has been received and
> processed.  An alternative is to use a control interface somewhat like
> INN does -- via a unix domain socket.
> 
> Dean
> 
> On Thu, 1 Jan 1998, Gregory A Lundberg wrote:
> 
> > On Thu, 1 Jan 1998, Marc Slemko wrote:
> > 
> > > Does it compress the logs at all?
> > 
> > Compress 'em?  Be glad they finally fixed the signals.  They still rotate
> > Samba logs without signalling causing the files to grow with zillions of
> > NUL bytes at the front.
> > 
> > ----
> > 
> > Gregory A Lundberg		Senior Partner, VRnet Company
> > 1441 Elmdale Drive              email: lundberg@vr.net [205.133.13.8]
> > Kettering, OH 45409-1615 USA    voice: +1 (937) 299-7653
> > 
> > 
> 
> 


Re: latest redhat rpm of apache

Posted by Dean Gaudet <dg...@arctic.org>.
Actually when I mailed ewt@redhat.com about the kill -9 problem he
asked me if there was any way for him to know the daemon had died.
I said there wasn't and was there another daemon that behaved in a way he
liked 'cause I could emulate it.  He said nope, it's a general problem,
a solution would be great.  So here's my proposed solution.

After setting up the pid file the parent acquires a sharable lock on it.
(The parent exits if the lock fails).  Each child also child acquires
a sharable lock.  flock() or fcntl() will work for this.

A support utility "waitlock filename timeout" attempts to acquire an
exclusive lock on filename.  Once it has acquired the exclusive lock
it exits with code 0.  On any error it exits with code 1, on timeout it
exits with code 2.

Then shutting down the server becomes:

    kill -TERM `cat /var/run/httpd.pid`
    waitlock /var/run/httpd.pid 600
    exit $?

I suppose you could do kill -9, but I kinda hate doing that even in
completely broken situations, especially in scripts.  "killall -9 httpd"
could take out completely unrelated httpds.

There's another use for this type of locking:  kill -USR1.  If you modify
the children to all share lock the log files, then doing a waitlock
after a rotation attempt will let you continue when all the children
have completed.  But this still isn't as nice in my opinion as using a
piped logger, because the piped logger can rotate immediately.

But I think this is a nice way to know a signal has been received and
processed.  An alternative is to use a control interface somewhat like
INN does -- via a unix domain socket.

Dean

On Thu, 1 Jan 1998, Gregory A Lundberg wrote:

> On Thu, 1 Jan 1998, Marc Slemko wrote:
> 
> > Does it compress the logs at all?
> 
> Compress 'em?  Be glad they finally fixed the signals.  They still rotate
> Samba logs without signalling causing the files to grow with zillions of
> NUL bytes at the front.
> 
> ----
> 
> Gregory A Lundberg		Senior Partner, VRnet Company
> 1441 Elmdale Drive              email: lundberg@vr.net [205.133.13.8]
> Kettering, OH 45409-1615 USA    voice: +1 (937) 299-7653
> 
> 


Re: latest redhat rpm of apache

Posted by Gregory A Lundberg <lu...@vr.net>.
On Thu, 1 Jan 1998, Marc Slemko wrote:

> Does it compress the logs at all?

Compress 'em?  Be glad they finally fixed the signals.  They still rotate
Samba logs without signalling causing the files to grow with zillions of
NUL bytes at the front.

----

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              email: lundberg@vr.net [205.133.13.8]
Kettering, OH 45409-1615 USA    voice: +1 (937) 299-7653


Re: latest redhat rpm of apache

Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 1 Jan 1998, Manoj Kasichainula wrote:

> > 	-ServerAdmin you@your.address
> > 	+ServerAdmin root@localhost
> > 
> > which I'm not sure helps anything...
> 
> Oopsie. I've been doing this as well. I guess that I should fix this.
> It'd be nice to have something that works out the box, though, or at
> least didn't provide an invalid address.

The idea is that you@your.address makes people who do see it know it is
bogus, and makes it obvious it needs to be changed.

If the box isn't networked to remote systems, root@localhost will have
meaning.  In that case, however, it is unlikely to have multiple users
using it so it doesn't matter.  If it is networked and has remote users
using the web server, root@localhost is completely wrong because it may
look like a valid address to some people yet will not work right and often
won't bounce either.

Some day I should fix all the example domains to make them correct example
domains.

> 
> > The latest Redhat 1.2 package still uses killall for log rotation:
> > 
> > 	/var/log/httpd/access_log {
> > 	    postrotate
> > 		/usr/bin/killall -HUP httpd
> > 	    endscript
> > 	}
> > 
> [same for agent_log, error_log, and referer_log]
> > 
> > Sigh.
> 
> I've mentioned this to them. In my RPMs, I've always eliminated the
> first three killall's, and I'm planning to change the fourth to a USR1
> signal.

Does it compress the logs at all?

> 
> > And for their httpd.init script they do:
> > 
> >   stop)
> >         echo -n "Shutting down http: "
> >         killproc httpd
> >         echo
> >         rm -f /var/lock/subsys/httpd
> >         ;;
> > 
> > (no idea what killproc does...)
> 
> The same thing as killall, but killproc is guaranteed to be available
> in rc.d scripts, while killall may never be available. Then why is it
> used in logrotate? Good question.

And what signal does it use?  TERM?

> 
> > but restart is the silly:
> > 
> >   restart)
> >         $0 stop
> >         $0 start
> >         ;;
> 
> Fixing this too. Will use -USR1.

You may want to consider -HUP because understanding what -USR1 does and
doesn't do can take more brainpower than HUP does.  If people want to use
it for logfile rotations of their own, etc. -USR1 could mess them up.

> 
> Do y'all consider the proxy module to be stable enough to be included
> in an all-inclusive server yet? If not, I'll remove it from my RPM.

I think it is stable enough, the problem is just that it is an ugly mess
of code, poorly integrated into the Apache API with some bogus protocol
implementations.


Re: latest redhat rpm of apache

Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Dec 31, 1997 at 08:41:26PM -0700, Marc Slemko wrote:
> (finally grabbed the utility from the rpm tools directory to strip the
> header junk off a .rpm, modified it to make it actually work, ran it,
> ungzipped, uncpioed, and looked through the latest package...

BTW, I'll soon be releasing my RPMs for Apache 1.3b3, independant of Red
Hat's (IBM gave me the okay for this). I'll run it by you first, and
provide it as a tar file for the RPM-challenged so you can avoid all
this.

> 	-ServerAdmin you@your.address
> 	+ServerAdmin root@localhost
> 
> which I'm not sure helps anything...

Oopsie. I've been doing this as well. I guess that I should fix this.
It'd be nice to have something that works out the box, though, or at
least didn't provide an invalid address.

> The latest Redhat 1.2 package still uses killall for log rotation:
> 
> 	/var/log/httpd/access_log {
> 	    postrotate
> 		/usr/bin/killall -HUP httpd
> 	    endscript
> 	}
> 
[same for agent_log, error_log, and referer_log]
> 
> Sigh.

I've mentioned this to them. In my RPMs, I've always eliminated the
first three killall's, and I'm planning to change the fourth to a USR1
signal.

> And for their httpd.init script they do:
> 
>   stop)
>         echo -n "Shutting down http: "
>         killproc httpd
>         echo
>         rm -f /var/lock/subsys/httpd
>         ;;
> 
> (no idea what killproc does...)

The same thing as killall, but killproc is guaranteed to be available
in rc.d scripts, while killall may never be available. Then why is it
used in logrotate? Good question.

> but restart is the silly:
> 
>   restart)
>         $0 stop
>         $0 start
>         ;;

Fixing this too. Will use -USR1.

Do y'all consider the proxy module to be stable enough to be included
in an all-inclusive server yet? If not, I'll remove it from my RPM.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Yes, I know a nose is not a butt." -- Darrell Fuhriman