https://bz.apache.org/bugzilla/show_bug.cgi?id=61662
--- Comment #4 from Luca Toscano <[email protected]> --- (In reply to Kai from comment #2) > Luca, > > I sincerely hope you're not suggesting I resolve a runtime configuration > conflict by recompiling the software. I was only trying to explain why apachectl behaves in the way that you described, that's all :) > More generally, in stead of ports.conf, apachectl needs to obey the server's > Listen directive, or have its own configuration file which can be updated in > tandem with the server config. Using httpd's configuration might not be the best way to configure apachectl, since you could, for example, have multiple Listens/ports combination but mod-status configured only for one virtualhost. > Having to modify a /usr/sbin/ script in order to make the tool work, which > is not persistent across upgrades, is utterly unacceptable design. I agree that apachectl status is not really configurable, but the functionality should not be there in the first place in my opinion. Checking the health of httpd can be done in several ways with other tools, that are build with some logic that knows where/how to get mod-status' data. Let me know if you have a use case that strictly requires apachectl status to work, and we can discuss what to do. Side note: I'd like to keep the conversation polite and constructive, since httpd is maintained by a community of people that have no interest in turning down ideas or improvements. So if you have a proposal or a patch that works for your use case you are free to submit it for review :) Thanks! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
