illegal instruction 4
I have a mod_perl based module running a service on an openVZ slice.
It was working fine for a few weeks, but when I went to use it today I
get delivered an empty page and in the apache error.log:
child exit signal Illegal instruction (4)
Which AFAIK is a very strange thing (SIGILL); actual perl errors are
usually explicit, and passed on from the interpreter. To make sure the
problem wasn't in my code, I replaced the module with a one liner:
sub handler {
return SERVER_ERROR;
}
Same thing. Ie, suddenly perl modules are working. I did not compile
apache or mod_perl myself.
Anyone have any ideas about how I can solve this or debug it further?
I have been playing around with small max stack sizes (ulimit -s 256),
but resetting that to 8192 and restarting apache did not alleviate the
problem.
--
Enthusiasm is not the enemy of the intellect. (said of Irving Howe)
The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: illegal instruction 4
On Thu, 7 Jul 2011 10:33:59 -0400 MK m...@cognitivedissonance.ca wrote: Same thing. Ie, suddenly perl modules are working. I did not compile apache or mod_perl myself. Sorry, that should read suddenly perl modules are NOT working, hopefully that was not too confusing ;) -- Enthusiasm is not the enemy of the intellect. (said of Irving Howe) The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: proxying another protocol to http/https
On Thu, Jul 7, 2011 at 02:56, Jodi Bosa jodib...@gmail.com wrote:
I would like to leverage mod_proxy and mod_proxy_http to proxy client
requests (from another protocol).
Assuming I have input output filters that handle the other protocol with
the client, shouldn't I simply be able to:
Handler
{
r-filename = apr_psprintf(r-pool, proxy:https://%s;, hostname);
r-proxyreq = PROXYREQ_PROXY;
return DECLINED; /* to allow mod_proxy to kick in and do it's thing */
}
That should work if your handler runs before mod_proxy. Hook it at
APR_HOOK_REALLY_FIRST.
Re: illegal instruction 4
On Thu, Jul 7, 2011 at 16:33, MK m...@cognitivedissonance.ca wrote:
I have a mod_perl based module running a service on an openVZ slice.
It was working fine for a few weeks, but when I went to use it today I
get delivered an empty page and in the apache error.log:
child exit signal Illegal instruction (4)
Which AFAIK is a very strange thing (SIGILL); actual perl errors are
usually explicit, and passed on from the interpreter. To make sure the
problem wasn't in my code, I replaced the module with a one liner:
sub handler {
return SERVER_ERROR;
}
Same thing. Ie, suddenly perl modules are working. I did not compile
apache or mod_perl myself.
Anyone have any ideas about how I can solve this or debug it further?
I have been playing around with small max stack sizes (ulimit -s 256),
but resetting that to 8192 and restarting apache did not alleviate the
problem.
I'm not sure if this is the right mailing list for you but if you want
to debug Apache, start it in single-process mode (`httpd -X`) and
attach `gdb` to it. That may be only nominally useful if your Apache
is compiled without debug symbols (unless you get a kick out of
stepping through assembly code).
Re: proxying another protocol to http/https
On Thu, Jul 7, 2011 at 5:18 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Thu, Jul 7, 2011 at 02:56, Jodi Bosa jodib...@gmail.com wrote:
I would like to leverage mod_proxy and mod_proxy_http to proxy client
requests (from another protocol).
Assuming I have input output filters that handle the other protocol with
the client, shouldn't I simply be able to:
Handler
{
r-filename = apr_psprintf(r-pool, proxy:https://%s;, hostname);
r-proxyreq = PROXYREQ_PROXY;
return DECLINED; /* to allow mod_proxy to kick in and do it's thing */
}
That should work if your handler runs before mod_proxy. Hook it at
APR_HOOK_REALLY_FIRST.
Or do it in a different hook like translate_name -- like proxy and rewrite do.
Re: creating reverse proxy workers dynamically
On Thu, Jul 7, 2011 at 07:19, Jodi Bosa jodib...@gmail.com wrote: It seems I may need to create HTTPS reverse proxy workers DYNAMICALLY - what is best way to do this? In other words, from manual I see config directive: ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30 However, I will have several origin servers that aren't necessarily known during config or startup. How can I create such workers as needed? I don't think there is a reliable way to do that right now.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Hi, I have an error log full of these; [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. Thanks to Steffen's bringing this up, I now know how I should be fixing this. The problem is, if I set AcceptFilter http none I lose all my vhosts and everything reverts to the main host. If I use AcceptFilter https none I have no ssl because of the same reason, it reverts to the main host which is not https and I get this in Firefox An error occurred during a connection to servertwo.tld. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) http://servertwo.tld:443 works, but isn't https, and doesn't serve the right document, it serves the document of the main host. Win32DisableAcceptEx never suffered this horrendous problem. What I am seeing in the error log is bizarre; [Thu Jul 07 01:25:28.419000 2011] [core:error] [pid 3332:tid 1532] [client 127.0.0.1:52880] request failed: invalid characters in URI What's invalid about https://servertwo.tld Vista or XP, same thing. Gregg On 7/4/2011 8:52 PM, William A. Rowe Jr. wrote: On 7/4/2011 9:46 AM, Steffen wrote: The widely used Win32DisableAcceptEx is not anymore in 2.3. Can someone confirm that this has the same effect: AcceptFilter http none AcceptFilter https none Maybe an idea to update the upgrading docu on this subject ? http://httpd.apache.org/docs/2.3/mod/core.html#acceptfilter AcceptEx() is supported with AcceptFilter data, or connect, per the documentation. AcceptEx() is not used for AcceptFilter none.
Re: Win 2.3.13 :: SSL issues rewrite
I think the issues with AcceptFilter http/s none should first be solved, my feeling says it is relating too. See also the post from Gregg today with subject Windows 2.3.13 :: Win32DisableAcceptEx. He suffers same kind of issues. Steffen - Original Message - From: Stefan Fritsch s...@sfritsch.de To: dev@httpd.apache.org Sent: Wednesday, July 06, 2011 9:55 PM Subject: Re: Win 2.3.13 :: SSL issues rewrite On Tuesday 05 July 2011, Steffen wrote: Was always working fine with 2.2.19, but with 2.3.13 I get: I call https://www.sjorsland.com/surgeweb/ : Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /surgeweb/. Reason: DNS lookup failure for: www.sjorsland.com:7080 Can you provide the log output of one request with LogLevel rewrite:trace4 proxy:trace2 proxy_http:trace2 ? You can also send it privately to me or priv...@httpd.apache.org, if you prefer.
[vote] mod_ldap
Only presently available options are available as choices to end this now unproductive discussion [any heretofore unseen complete abstration of ldap cannot be considered with no patches offered]. This vote is limited to the scope of the httpd project and expresses a preference, there is no technical basis demonstrated to carry a veto. [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) [ ] Move ap_ldap API's to the core (binding both httpd and mod_ldap to ldap libs) [ ] Move ap_ldap API's to yet another mod_ldaps[1] module (binding both mod_ldap and mod_ldaps to ldap libs) [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) [ ] Remove mod_authnz_ldap / mod_ldap from httpd 2.3 [1] other name suggestions are welcome [2] vote thread removing ldap from apr-2.x; http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3c4bd46614.6010...@rowe-clan.net%3E http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3caanlktinkzmdybxo2vggzloxpy72mh0orek-kuesgj...@mail.gmail.com%3E
Re: httpd ldap mess
On 7/6/2011 6:07 PM, Graham Leggett wrote: I have vetoed the mess you've just referred to, and I expect wrowe to revert this change as per this project's rules. Per the project rules, you have failed to offer a valid technical justification for your veto. It represents an opinion. Right now, I have a much technical justification than you, due to the fact that updating apr-util and replacing the ldap library consumed by apr-util breaks an installed mod_ldap, violating binary compatibility guidelines. If this is still not done by the end of the week I will make plans to do so myself, however I am currently arranging a wedding, and that comes first right now. Do not unilaterally revert. Doing so based on an unsubstantiated veto jeopardizes your commit privileges. Speaking for a moment as project chair, I will not permit svn to be abused with commit wars. I have put this to a [vote] as you had not done so, since you desire some path to change the current direction. Others at this list have expressed an interest in working with the current state of trunk. I've just completed a rather intensive project and can again dedicate cycles to further testing and improving the status quo for 2.3 beta. I do know that things built on linux and win32 when I had last looked, but that was only with wldap32.dll and openldap tests. As we fix one thing, it is altogether possible that we break something else, and I'm happy to help clean up today. Complete refactoring at httpd would permit us to build mod_ldap_openldap alongside other library options, something apr_util cannot provide.
Re: [vote] mod_ldap
On Thu, Jul 7, 2011 at 12:55 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Only presently available options are available as choices to end this now unproductive discussion [any heretofore unseen complete abstration of ldap cannot be considered with no patches offered]. This vote is limited to the scope of the httpd project and expresses a preference, there is no technical basis demonstrated to carry a veto. [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) yes, unless I misunderstood option #3 [ ] Move ap_ldap API's to the core (binding both httpd and mod_ldap to ldap libs) no [ ] Move ap_ldap API's to yet another mod_ldaps[1] module (binding both mod_ldap and mod_ldaps to ldap libs) IIUC, the only benefit (and a great one) to yet another ldap shared library (whether mod_foo or in apr) is if there is a complete abstraction, such that only one shared library binds to libldap* and that one shared library can be switched out to switch client libraries and libldap* symbol use doesn't leak between different functional areas. Is there some other possibility? [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) no [ ] Remove mod_authnz_ldap / mod_ldap from httpd 2.3 no [1] other name suggestions are welcome [2] vote thread removing ldap from apr-2.x; http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3c4bd46614.6010...@rowe-clan.net%3E http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3caanlktinkzmdybxo2vggzloxpy72mh0orek-kuesgj...@mail.gmail.com%3E -- Born in Roswell... married an alien...
Re: [discuss] mod_ldap
On 7/7/2011 12:14 PM, Jeff Trawick wrote: [ ] Move ap_ldap API's to yet another mod_ldaps[1] module (binding both mod_ldap and mod_ldaps to ldap libs) IIUC, the only benefit (and a great one) to yet another ldap shared library (whether mod_foo or in apr) is if there is a complete abstraction, such that only one shared library binds to libldap* and that one shared library can be switched out to switch client libraries and libldap* symbol use doesn't leak between different functional areas. Is there some other possibility? As things stand, if mod_ldap provides all of the fundamental interop, it would be the only module that needs to be swapped out, which is why I'm partial to option #. It looks like the only function invoked by mod_authnz_ldap in ldap libs themselves is ldap_add(). If that were abstracted, mod_authnz_ldap would have no bindings to the ldap impl. I don't care for option #3 unless mod_ldap entirely consumes the new module and does not, itself, need to be bound to the ldap provider. Another approach to #3 is to rename it to correspond to Graham's claim of its scope, and to call the ap_ldap functionality as mod_ldap.
Re: [vote] mod_ldap
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. [ ] Move ap_ldap API's to the core (binding both httpd and mod_ldap to ldap libs) Clear -1. [ ] Move ap_ldap API's to yet another mod_ldaps[1] module (binding both mod_ldap and mod_ldaps to ldap libs) -0. KISS. [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) -1. OK for a hack, but not for a 2.4 release. Eat our own dogfood. [ ] Remove mod_authnz_ldap / mod_ldap from httpd 2.3 -1. Not an acceptable regression from 2.2. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: [vote] mod_ldap
On Jul 7, 2011, at 2:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. +1
Re: load order dependency between mod_ldap and mod_authnz_ldap
On 04 Jul 2011, at 6:48 PM, Joe Orton wrote: It's incumbent on you to provide specific technical objections if vetoing code, not this hand-waving objections must exist because of X. I have already done so. If you disagree with the objection, or do not understand the objection, engage the objection directly so it can be resolved. The removal from APR was because the API does not match design of the other APIs in APR, because it is an incomplete abstraction - mod_ldap must use the underlying LDAP API directly as well as the wrapper functions. This is not something which translates directly across to httpd; the exported API from mod_ldap was already an incomplete abstraction, adding more exports does not change that. Indeed, it explains the motivation for consolidating this stuff in one place. We are not discussing the removal of apr_ldap from APR, we are discussing the addition of ap_ldap to httpd. Wrowe's reasons for removing apr_ldap from APR are very valid and real, the incomplete abstraction is wrong, and sf has already explained the problems that are caused when libraries and/or modules compiled with different LDAP library are linked to the same server. These problems are not in any shape or form solved by moving apr_ldap to httpd, the move serves no purpose whatsoever. Over and above this zero nett gain, we now have two nett losses: - We now suffer an abstraction API in httpd, when all other abstraction APIs are in APR. I personally don't care whether the abstraction libraries are in APR proper, in apr-util, in apr-ldap or httpd-helper-libraries, what I do care is that all abstraction APIs should be treated the same way. I have not seen any discussion to suggest that there are any plans to move DBD, DBM, crypto and XML, nor have I seen anyone justify why we are using an inconsistent approach in our architecture. - We currently build against 7 different LDAP APIs on a multitude of different platforms. Without the courtesy of any warning or discussion, maintainers of various platforms are now expected to spend their time and money making this code build again in the httpd codebase. What is the payoff for them? Nothing. Wrowe has attempted to justify his addition of ap_ldap to httpd by saying because httpd would not have been happy if it had abandoned these helpers and they were not present for httpd's consumption, however this statement is not true - LDAP is present in apr-util, and will always be present as per the versioning rules of APR. In addition, the versioning rules of apr-util allow us to add to the API and in so doing complete the abstraction, solving the problem in apr-util v1.4 or v1.5. That makes this entire move unnecessary and a huge waste of time. I am confident that the httpd people will address the APR v2.0 LDAP issue, but only after httpd v2.4 is baked, people have time again, and APR v2.0 starts becoming something less than vapourware. If you have specific concerns with exposing all the ap[r]_ldap_* API from httpd, then that is something we can maybe resolve; it looks like mod_authnz_ldap and mod_vhost_ldap only require the url_parse hook, so maybe we could cut the additional exported API back down to that? A cut down LDAP API is useless to anybody wishing to bind to an LDAP API and use its complete functionality, unless the API is complete, we are wasting the end user's time. Long ago we moved away from this portability nonsense, delegating the job to APR. Moving this all back to httpd is ugly in the extreme. You allude to build issues without giving details, what's still broken? (Thanks Stefan for fixing my own screwup) See at least the following threads: - Thread ending with [VOTE REVOKED] Re: [VOTE] Release Apache httpd-2.3.13 as beta - httpd LDAP mess In the case of MacOSX, it breaks for me as follows: checking whether to enable mod_authnz_ldap... checking dependencies checking whether to enable mod_authnz_ldap... configure: error: mod_authnz_ldap has been requested but can not be built due to prerequisite failures Regards, Graham --
Re: [vote] mod_ldap
On 07 Jul 2011, at 10:51 PM, Jim Jagielski wrote: On Jul 7, 2011, at 2:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. +1 +1. Regards, Graham --
Re: [vote] mod_ldap
On 7/7/2011 5:16 PM, Graham Leggett wrote: On 07 Jul 2011, at 10:51 PM, Jim Jagielski wrote: On Jul 7, 2011, at 2:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. +1 +1. +1 Since it's being pulled from APR, this is the most sane place to put it in order to maintain the functionality for httpd. -- -- Daniel Ruggeri
Re: [discuss] mod_ldap
On 7/7/2011 1:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. Yes, /someone/ should have acted on the decision of mid-2009 back in that year ;P Since it fell onto me, and I didn't want apr 2.0 to break our httpd 2.4 during its lifespan, well... at least the code came across complete, except for the APU_DSO logic which makes no sense (why would we dynamically link to ldap when the module is already bound to ldap?) As this code and config logic had existed for some time, I expected the entire move to be relatively less painful than it appears to be. Define 'botch job'; I understand that, right now, we are not happy with the placement of the AP_HAS_LDAP symbol, that we were not happy with the load order dependency of mod_ldap loading before mod_authnz_ldap (fixed by jorton, rjung and sf). Other than resolving where AP_HAS_LDAP should be declared, what are the other concerns? That wouldn't rise to my definition of a botch job. My understanding is that there is a veto on the addition of ap_ldap API's in win32 (which Graham's vote would appear to void). Is there a much more narrow veto present? I suspect we have one flag too many to indicate the presence of an LDAP provider and will remedy this in ap_config_auto.h/ap_config.hw|hnw.
Re: load order dependency between mod_ldap and mod_authnz_ldap
On 25 Jun 2011, at 21:11, Graham Leggett wrote: This is not so, to fix this, you would need to wrap every single LDAP API function call[1] in an optional function, and if you did that, you would solve the problem that caused you to want to remove apr_ldap from APR in the first place, making the whole exercise pointless - you may as well just have fixed apr-ldap in place. In view of the escalation of this argument, I'm trying to review the history and see if I can get to grips with the underlying problem. It seems this is where your objection starts, right? If it matters, I'm trying not to take sides here, and I too find it uncomfortable when Bill gets abrasive in a public list. But isn't the above a slight misstatement of the issue? ap_ldap (and apr_ldap before) wraps only a subset of the LDAP API, that subset is what in fact has to be wrapped in optional functions. I don't see a problem with that: more optional functions can be introduced as and when more APIs are exposed. And optional functions can exist alongside regular API functions, as in mod_dbd.h, as and when you or anyone do it. The timing cannot be worse - an already suboptimal API plus these new bugs are being dumped into httpd in the final stages of trying to bake the final version of httpd v2.4.0, which means we will be stuck with this brokenness through the life of httpd v2.4. Up to a point. We're full of compromises, some nicer, some uglier. But what *new* bugs are you referring to that aren't fixed by optional functions? Would it make sense to introduce a mod_dbd-like parallel API, and does it break anything that would prevent you hacking it within the lifetime of 2.4? There is no need for this move at all, as httpd works perfectly against APR v1.x (or did until this change). APR v2.x hasn't gone through any kind of stabilisation phase, never mind seen an alpha or beta release, and so httpd v2.4.x being compatible with apr-trunk at this stage is not necessary, especially seeing that when httpd v2.4 is released, it's API is set in stone, but APR v2.0's API remains in flux. Or to put it another way, the fact that apr_ldap is missing from apr-trunk is not a problem for httpd v2.4, and can be solved after httpd v2.4. That's a fair point. If you can convince me there are NEW unsolved bugs, I may support it. But I wouldn't agree with excluding APR2 use if these new bugs are (no more than) what optional functions solve. Nor do I think now is the right time to make an issue of defects that are equally present in ap_ldap and in apr_ldap before. I am therefore vetoing this move of apr_ldap from APR to httpd. Hang on! How long ago did this move happen, and when did you first raise concerns? -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: load order dependency between mod_ldap and mod_authnz_ldap
On 7/7/2011 9:10 PM, Nick Kew wrote: I am therefore vetoing this move of apr_ldap from APR to httpd. Hang on! How long ago did this move happen, and when did you first raise concerns? His first attempt at vetoing this change was in 2009, accompanied by an assertion that he would address the issues. Of course, nobody expects any individual to provide specific code to do anything, but that doesn't excuse the promise of action or requests for unending dialog without code to slow a project for two years; http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/%3c5c902b9e0903240326r3222ac90k15dcb7f34d2d1...@mail.gmail.com%3E [One will note Graham isn't arguing against my proposal, but Justin's.] That that time, Graham's response was that decisions should not be made offlist at a face to face, which was patently absurd on the face of it, since Justin brought a decision to the list, rather than act on the conversations he had with individual committers. Following inaction on the [endless] discussion in this thread and others, I finally proposed an absolute eviction, to which Graham did not respond; http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3c4bd46614.6010...@rowe-clan.net%3E [and following on in May...] http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3caanlktinkzmdybxo2vggzloxpy72mh0orek-kuesgj...@mail.gmail.com%3E
Remaining LDAP issues?
Starting a fresh thread to identify the actual issues that are blocking the 2.3.13-beta, along with fresh checkouts and build trees... I immediately noticed that it's confusing that --enable-authnz-ldap etc don't work without --with-ldap. What configuration logic could make this all easier for users who want ldap auth?
