On Fri, Dec 4, 2009 at 12:37 PM, Graham Leggett <[email protected]> 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
