You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by mi...@apache.org on 2009/11/30 23:53:43 UTC

svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Author: minfrin
Date: Mon Nov 30 22:53:43 2009
New Revision: 885606

URL: http://svn.apache.org/viewvc?rev=885606&view=rev
Log:
Rpm package: pass the HTTPD_LANG variable to the httpd process in line
with Fedora. Remove the use of the apachectl script, as a script calling
another script makes no sense. Test for the pidfile specifically, so
that Redhat's scripts don't fall back to using pidof and returning the
status of other httpd processes running on the same box.

Modified:
    httpd/httpd/trunk/build/rpm/httpd.init

Modified: httpd/httpd/trunk/build/rpm/httpd.init
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/build/rpm/httpd.init?rev=885606&r1=885605&r2=885606&view=diff
==============================================================================
--- httpd/httpd/trunk/build/rpm/httpd.init (original)
+++ httpd/httpd/trunk/build/rpm/httpd.init Mon Nov 30 22:53:43 2009
@@ -42,6 +42,9 @@
         . /etc/sysconfig/httpd
 fi
 
+# Start httpd in the C locale by default.
+HTTPD_LANG=${HTTPD_LANG-"C"}
+
 # This will prevent initlog from swallowing up a pass-phrase prompt if
 # mod_ssl needs a pass-phrase from the user.
 INITLOG_ARGS=""
@@ -50,8 +53,6 @@
 # with the thread-based "worker" MPM; BE WARNED that some modules may not
 # work correctly with a thread-based MPM; notably PHP will refuse to start.
 
-# Path to the apachectl script, server binary, and short-form for messages.
-apachectl=/usr/sbin/apachectl
 httpd=${HTTPD-/usr/sbin/httpd}
 prog=httpd
 pidfile=${PIDFILE-/var/log/httpd/httpd.pid}
@@ -81,7 +82,7 @@
 start() {
         echo -n $"Starting $prog: "
         check13 || exit 1
-        daemon --pidfile=${pidfile} $httpd $OPTIONS
+        LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS
         RETVAL=$?
         echo
         [ $RETVAL = 0 ] && touch ${lockfile}
@@ -111,15 +112,20 @@
 	stop
 	;;
   status)
-        status -p ${pidfile} $httpd
-	RETVAL=$?
-	;;
+        if ! test -f ${pidfile}; then
+            echo $prog is stopped
+            RETVAL=3
+        else  
+            status -p {$pidfile} $httpd
+            RETVAL=$?
+        fi
+        ;;
   restart)
 	stop
 	start
 	;;
   condrestart)
-	if status -p ${pidfile} $httpd >&/dev/null; then
+	if test -f ${pidfile} && status -p ${pidfile} $httpd >&/dev/null; then
 		stop
 		start
 	fi
@@ -127,13 +133,20 @@
   reload)
         reload
 	;;
-  graceful|help|configtest|fullstatus)
-	$apachectl $@
-	RETVAL=$?
-	;;
+  configtest)
+        LANG=$HTTPD_LANG $httpd $OPTIONS -t
+        RETVAL=$?
+        ;;
+  graceful)
+        echo -n $"Gracefully restarting $prog: "
+        LANG=$HTTPD_LANG $httpd $OPTIONS -k $@
+        RETVAL=$?
+        echo
+        ;;
   *)
-	echo $"Usage: $prog {start|stop|restart|condrestart|reload|status|fullstatus|graceful|help|configtest}"
+	echo $"Usage: $prog {start|stop|restart|condrestart|reload|status|graceful|help|configtest}"
 	exit 1
 esac
 
 exit $RETVAL
+



Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Eric Covener <co...@gmail.com>.
On 12/4/09, Tom Evans <te...@googlemail.com> wrote:
> Sorry, what has apachectl got to do with editing files? What has using
>  apachectl to stop/start a service got to do with scalability? You've
>  completely lost me here.

The only practical thing i can think of is OS vendors providing
separate worker and prefork binaries. The standard apachectl has the
binary name embedded in it, although there are a host of ways to
accomodate that.

-- 
Eric Covener
covener@gmail.com

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Tom Evans <te...@googlemail.com>.
On Fri, Dec 4, 2009 at 12:37 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Tom Evans wrote:
>
>> Really? It works perfectly on all boxes I use it on. What precisely
>> has changed about reading a pid from a file, sending signals to a
>> process, or spawning a process with specific arguments that has made
>> apachectl 'archaic and largely broken', I am intrigued.
>
> And if you have ten boxes? 50 boxes? A Google of boxes?
>
> Editing a file in place has long been shown to be a maintenance
> nightmare, which is why in addition to logrotate.conf you have
> logrotate.d, in addition to modprobe.conf you have modprobe.d, and so
> on. This is a pattern long since established in modern unix
> distributions, to solve the problem of the need to edit files during a
> software addition, and edit files again during software removal, all
> without making mistakes.
>
> Sure, if you are used to editing config files by hand on one or two
> boxes, apachectl will meet your needs, but if you do anything that
> requires a level of scale doing it this way won't.
>
> Regards,
> Graham
> --
>

Sorry, what has apachectl got to do with editing files? What has using
apachectl to stop/start a service got to do with scalability? You've
completely lost me here.

At $JOB we have 200+ servers, all deployed and configured via
cfengine. apachectl is still used to stop/start the servers, via
cfengine and other CM tools.

Cheers

Tom

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
Tom Evans wrote:

> Really? It works perfectly on all boxes I use it on. What precisely
> has changed about reading a pid from a file, sending signals to a
> process, or spawning a process with specific arguments that has made
> apachectl 'archaic and largely broken', I am intrigued.

And if you have ten boxes? 50 boxes? A Google of boxes?

Editing a file in place has long been shown to be a maintenance
nightmare, which is why in addition to logrotate.conf you have
logrotate.d, in addition to modprobe.conf you have modprobe.d, and so
on. This is a pattern long since established in modern unix
distributions, to solve the problem of the need to edit files during a
software addition, and edit files again during software removal, all
without making mistakes.

Sure, if you are used to editing config files by hand on one or two
boxes, apachectl will meet your needs, but if you do anything that
requires a level of scale doing it this way won't.

Regards,
Graham
--

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Tom Evans <te...@googlemail.com>.
On Fri, Dec 4, 2009 at 12:59 AM, Graham Leggett <mi...@sharp.fm> wrote:
> William A. Rowe Jr. wrote:
>
>> Ok, so they want to roll their own.  Sounds like a maintainer issue.  What
>> does this say for using our httpd rpm for an Ubuntu or other distribution
>> of linux?
>
> Ubuntu is Debian based, and uses the .deb packaging format, and startup
> scripts derived from the Debian layout. If someone was to donate debian
> packaging for httpd, I would expect one or two files to appear below
> build/deb, and that would be all that would be needed.
>
>> IMHO, if it is fundamentally incompatible with apachectl and non-redhat
>> distributions, let the the packagers tweak and take the zany customizations
>> out from under our problem set.
>
> Apachectl is archaic and largely broken for most people - it made sense
> ten years ago, it makes a lot less sense today.

Really? It works perfectly on all boxes I use it on. What precisely
has changed about reading a pid from a file, sending signals to a
process, or spawning a process with specific arguments that has made
apachectl 'archaic and largely broken', I am intrigued.


>
> The pattern followed by most modern unix based packaging is for an
> application to drop a snippet of config contained in a discrete file in
> a directory ending in ".d". So you have
> /etc/httpd/conf.d/<snippet>.conf, instead of a manual edit to
> /etc/httpd/conf/httpd.conf, and your httpd startup goes within an
> optional script called /etc/sysconfig/httpd instead of in a script file
> in a bin directory as apachectl wants. I understand Debian has different
> naming conventions, but otherwise the underlying principles are the same.

Did you mean to say 'most Linux' there? The OSes that I regularly use
do not display these redhatisms.

>
> In our case, we package up config files within standalone RPMs all of
> their own (suitably tagged and versioned), or we generate the config
> file using puppet. Editing a file in place is always painful and error
> prone, it is far less painful to provide a discrete file that can be
> dropped in and removed cleanly. Apachectl doesn't give us this - you
> need to edit apachectl directly to modify the command line parameters
> passed to httpd.
>
> As for the packagers tweaking and making zany customisations, that is
> exactly what they do now. For us it makes the their packaging unsuitable
> for our needs, simply because we tweak and make zany customisations for
> needs of our own. It is far less painful to take a vanilla RPM published
> by the ASF, and then tweak it for our needs, than it is to take a Fedora
> RPM, untweak all their customisations, and then retweak it with ours.
>

Ah so now the crux of your argument:

1) I use Fedora/RHEL
2) I want customized packages to install
3) Fedora/RHEL package their RPMs in such a way that it makes it
difficult for me to modify them.

It's much easier when you just say this up front.

Cheers

Tom

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe Jr. wrote:

> The last I heard, the 'rpm' project is open source, free to be adopted by
> any platform.

Just because rpm is free to be adopted by any platform doesn't mean it
has been. Rpm contains features that allow the spec file to tailor
itself to its build environment, and I am confident those features would
kick in if someone was to try and create an rpm package tailored for an
environment other than a Redhat derivative.

> As for the rest of your comments, if we solve the general problem, I'm all
> for including it in the httpd tree.  If we are solving specific packagers
> problems, I'm ok with placing this in the httpd.a.o domain, but we should
> move this nonsense outside of the development tree into a packaging tree.

And in turn violate the principle of least surprise.

The point behind support for packaging formats is to make the end user's
life easier, not harder. Packagers that create weird, non standard, or
unexpectedly complex packaging are not doing their users any favours.

Regards,
Graham
--


Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
> William A. Rowe Jr. wrote:
> 
>> Ok, so they want to roll their own.  Sounds like a maintainer issue.  What
>> does this say for using our httpd rpm for an Ubuntu or other distribution
>> of linux?
> 
> Ubuntu is Debian based, and uses the .deb packaging format, and startup
> scripts derived from the Debian layout.

The last I heard, the 'rpm' project is open source, free to be adopted by
any platform.

As for the rest of your comments, if we solve the general problem, I'm all
for including it in the httpd tree.  If we are solving specific packagers
problems, I'm ok with placing this in the httpd.a.o domain, but we should
move this nonsense outside of the development tree into a packaging tree.

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe Jr. wrote:

> Ok, so they want to roll their own.  Sounds like a maintainer issue.  What
> does this say for using our httpd rpm for an Ubuntu or other distribution
> of linux?

Ubuntu is Debian based, and uses the .deb packaging format, and startup
scripts derived from the Debian layout. If someone was to donate debian
packaging for httpd, I would expect one or two files to appear below
build/deb, and that would be all that would be needed.

> IMHO, if it is fundamentally incompatible with apachectl and non-redhat
> distributions, let the the packagers tweak and take the zany customizations
> out from under our problem set.

Apachectl is archaic and largely broken for most people - it made sense
ten years ago, it makes a lot less sense today.

The pattern followed by most modern unix based packaging is for an
application to drop a snippet of config contained in a discrete file in
a directory ending in ".d". So you have
/etc/httpd/conf.d/<snippet>.conf, instead of a manual edit to
/etc/httpd/conf/httpd.conf, and your httpd startup goes within an
optional script called /etc/sysconfig/httpd instead of in a script file
in a bin directory as apachectl wants. I understand Debian has different
naming conventions, but otherwise the underlying principles are the same.

In our case, we package up config files within standalone RPMs all of
their own (suitably tagged and versioned), or we generate the config
file using puppet. Editing a file in place is always painful and error
prone, it is far less painful to provide a discrete file that can be
dropped in and removed cleanly. Apachectl doesn't give us this - you
need to edit apachectl directly to modify the command line parameters
passed to httpd.

As for the packagers tweaking and making zany customisations, that is
exactly what they do now. For us it makes the their packaging unsuitable
for our needs, simply because we tweak and make zany customisations for
needs of our own. It is far less painful to take a vanilla RPM published
by the ASF, and then tweak it for our needs, than it is to take a Fedora
RPM, untweak all their customisations, and then retweak it with ours.

Regards,
Graham
--

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
> 
> On a Redhat machine (Fedora/RHEL/Centos), search
> /etc/rc.d/init.d/functions for functions called "daemon", "status" and
> "killproc". These functions provide similar but incompatible
> functionality to that provided by apachectl, and only exist on Redhat
> derived machines.

Ok, so they want to roll their own.  Sounds like a maintainer issue.  What
does this say for using our httpd rpm for an Ubuntu or other distribution
of linux?

> The startup script is far too trivial to justify jumping through hoops
> to try and make apachectl work like Redhat's init. It's caused us enough
> grief already, thus the fix.

IMHO, if it is fundamentally incompatible with apachectl and non-redhat
distributions, let the the packagers tweak and take the zany customizations
out from under our problem set.

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
Dan Poirier wrote:

> Well, apachectl doesn't provide any of that functionality.  About all it
> does is source bin/envvars, if it exists, and then call httpd and pass
> along any command line arguments.  httpd does all the start/stop/restart
> etc. logic internally.  
> 
> So I'm still not seeing the problem with setting httpd=apachectl in
> httpd.init, which would make bin/envvars apply, and not really change
> the behavior otherwise.

You've said it yourself, "apachectl doesn't provide that functionality".

In the Redhat world, environment vars are set in the file
/etc/sysconfig/httpd, not /usr/bin/envvars. Redhat's "service httpd
restart" works differently to apachectl's "apachectl restart".

>> It's caused us enough grief already, thus the fix.
> 
> What grief is that?  I don't actually know what problem we're trying to
> fix here.

Look in the original init script before the fix - start, stop and
restart were done using Redhat's functions and the settings in
/etc/sysconfig/httpd. graceful and status used apachectl and the (non
existent) /usr/sbin/envvars file.

That meant for us that the server's config behaved differently if the
admin did "service httpd graceful" and "service httpd restart", and was
very broken.

Regards,
Graham
--

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Dan Poirier <po...@pobox.com>.
Graham Leggett <mi...@sharp.fm> writes:

> Dan Poirier wrote:
>
>>> Redhat's init scripts don't work anything like the apachectl script, and
>>> trying to call one from the other causes the exact problem you mention -
>>> loss of environment variables, and all round weirdness.
>> 
>> Maybe I'm just slow getting back up to speed after the holiday, but I'm
>> not seeing how it would cause a problem.  Could you please expand on
>> that?
>
> On a Redhat machine (Fedora/RHEL/Centos), search
> /etc/rc.d/init.d/functions for functions called "daemon", "status" and
> "killproc". These functions provide similar but incompatible
> functionality to that provided by apachectl, and only exist on Redhat
> derived machines.

Well, apachectl doesn't provide any of that functionality.  About all it
does is source bin/envvars, if it exists, and then call httpd and pass
along any command line arguments.  httpd does all the start/stop/restart
etc. logic internally.  

So I'm still not seeing the problem with setting httpd=apachectl in
httpd.init, which would make bin/envvars apply, and not really change
the behavior otherwise.

> The startup script is far too trivial to justify jumping through hoops
> to try and make apachectl work like Redhat's init.

That's not what I was suggesting, and I don't think it would be
necessary.

> It's caused us enough grief already, thus the fix.

What grief is that?  I don't actually know what problem we're trying to
fix here.

Dan

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
Dan Poirier wrote:

>> Redhat's init scripts don't work anything like the apachectl script, and
>> trying to call one from the other causes the exact problem you mention -
>> loss of environment variables, and all round weirdness.
> 
> Maybe I'm just slow getting back up to speed after the holiday, but I'm
> not seeing how it would cause a problem.  Could you please expand on
> that?

On a Redhat machine (Fedora/RHEL/Centos), search
/etc/rc.d/init.d/functions for functions called "daemon", "status" and
"killproc". These functions provide similar but incompatible
functionality to that provided by apachectl, and only exist on Redhat
derived machines.

The startup script is far too trivial to justify jumping through hoops
to try and make apachectl work like Redhat's init. It's caused us enough
grief already, thus the fix.

Regards,
Graham
--

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Dan Poirier <po...@pobox.com>.
Graham Leggett <mi...@sharp.fm> writes:

> Redhat's init scripts don't work anything like the apachectl script, and
> trying to call one from the other causes the exact problem you mention -
> loss of environment variables, and all round weirdness.

Maybe I'm just slow getting back up to speed after the holiday, but I'm
not seeing how it would cause a problem.  Could you please expand on
that?

-- 
Dan Poirier <po...@pobox.com>

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
Dan Poirier wrote:

>> Remove the use of the apachectl script, as a script calling
>> another script makes no sense. 
> 
> I wonder if this is a good idea?
> 
> apachectl does some things that httpd.init does not.  For example, an
> admin might reasonably expect to be able to control Apache's environment
> by editing bin/envvars, but this will now silently fail when Apache is
> installed using RPM.
> 
> Of course httpd.init could also source bin/envvars, but then we start
> down the road of having to keep httpd.init in sync with apachectl.
> 
> I think we should just use the documented, recommended way of
> controlling apache.  The extra cost seems minimal, especially compared
> to the long-term maintenance costs of not doing so.

Redhat's init scripts don't work anything like the apachectl script, and
trying to call one from the other causes the exact problem you mention -
loss of environment variables, and all round weirdness.

Apachectl is simply a way of starting httpd, it is certainly not the
only way, and is definitely not the way you start if if you're on a
Redhat derived platform.

Regards,
Graham
--

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
> 
> We would either need to change apachectl to work like Redhat (triggering
> a storm of protest from people who do use apachectl and would ask "if it
> wasn't broken why did you fix it"), or change Redhat to work like
> apachectl (not worth the effort).

Or change apachectl to act silently to assist httpd.init.

In fact, a silent mode makes a lot of sense, httpd.init wouldn't be the
only consumer.

apachectl should be called-not-exec'ed, IMHO (just as apachectl calls
envvars).


Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe Jr. wrote:

> Is it reasonable to simply provision apachectl as httpd.init, perhaps even
> as a symlink?

Unfortunately not, no.

Redhat provides a library of functions to be used by startup scripts
that daemonise processes, keep track of pids, and do all the cute
displaying of "OK" or "Failed", and make the "service" command work
properly.

Apachectl, while similar to Redhat's init script, has different
semantics when faced with "restart", and the standard Redhat setup
doesn't work at all.

We would either need to change apachectl to work like Redhat (triggering
a storm of protest from people who do use apachectl and would ask "if it
wasn't broken why did you fix it"), or change Redhat to work like
apachectl (not worth the effort).

Regards,
Graham
--

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Dan Poirier wrote:
> minfrin@apache.org writes:
> 
>> Author: minfrin
>> Date: Mon Nov 30 22:53:43 2009
>> New Revision: 885606
>>
>> URL: http://svn.apache.org/viewvc?rev=885606&view=rev
>> Log:
> ...
>> Remove the use of the apachectl script, as a script calling
>> another script makes no sense. 
> 
> I wonder if this is a good idea?
> 
> apachectl does some things that httpd.init does not.  For example, an
> admin might reasonably expect to be able to control Apache's environment
> by editing bin/envvars, but this will now silently fail when Apache is
> installed using RPM.
> 
> Of course httpd.init could also source bin/envvars, but then we start
> down the road of having to keep httpd.init in sync with apachectl.
> 
> I think we should just use the documented, recommended way of
> controlling apache.  The extra cost seems minimal, especially compared
> to the long-term maintenance costs of not doing so.

Is it reasonable to simply provision apachectl as httpd.init, perhaps even
as a symlink?

Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init

Posted by Dan Poirier <po...@pobox.com>.
minfrin@apache.org writes:

> Author: minfrin
> Date: Mon Nov 30 22:53:43 2009
> New Revision: 885606
>
> URL: http://svn.apache.org/viewvc?rev=885606&view=rev
> Log:
...
> Remove the use of the apachectl script, as a script calling
> another script makes no sense. 

I wonder if this is a good idea?

apachectl does some things that httpd.init does not.  For example, an
admin might reasonably expect to be able to control Apache's environment
by editing bin/envvars, but this will now silently fail when Apache is
installed using RPM.

Of course httpd.init could also source bin/envvars, but then we start
down the road of having to keep httpd.init in sync with apachectl.

I think we should just use the documented, recommended way of
controlling apache.  The extra cost seems minimal, especially compared
to the long-term maintenance costs of not doing so.

Dan