httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Evans <>
Subject Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Date Fri, 04 Dec 2009 12:54:25 GMT
On Fri, Dec 4, 2009 at 12:37 PM, Graham Leggett <> 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.



View raw message