I've been trying to get RApache set up properly on my Macbook Pro running OS X 10.5.8. After installing RApache successfully (I think), I added the following to the httpd.conf file as suggested in the manual.
LoadModule R_module /apache/module/path/mod_R.so
ROutputErrors
<Location /RApacheInfo>
SetHandler r-info
</Location>
With these additions, I was then able to successfully go to http://localhost/RApacheInfo and see the status information. If I add the following additional line,
REvalOnStartup "library(brew)"
I can no longer load the RApacheInfo page successfully.
I don't know what the issue is here. Without the REvalOnStartup call, I'm seeing the following in the Apache error log.
[Fri Feb 26 11:36:36 2010] [notice] Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.7l DAV/2 mod_R/1.1.8 R/2.10.1 configured -- resuming normal operations
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
Not a good sign. Any thoughts on what might be going on? Or things to check?
Chris
I'm not sure why you're getting this error on just loading a library, but we've seen this issue on Leopard due to Apple's freetype/fontconfig/cairo libraries calling CoreFoundation calls:
http://finzi.psych.upenn.edu/R/Rhelp02/archive/118681.html
How did you install R?
I tried reproducing your issue on Snow Leopard with stock apache2, binary R 2.10.1 from CRAN, Xcode 3.2.1, and rapche 1.1.8 but no luck. My setup worked like a champ.
I don't have access to Leopard anymore, so my best suggestion is to use gdb to break on that really long system call. You will want to remove the REvalonStartup directive and replace it with a handler call which does the same, configure apache to spawn only one child process (hence the whole fork thing) and connect gdb to it. Then point your web browser to your handler url and see if gdb breaks on the function and then look at the stack trace.... Pretty lame I know, but that's all I got for now.
Related
Problem is the plain vanila apache is working, the moment I say sslEngine ON
it gives error, I am not able to find where any ssl setup is?
it does not create any log as well..
How this ssl setup is done? will copying a mod_ssl.so file from outside will work?
Apache version : 2.4.29
Os is RHEL 6.7
If this Red Hat documentation is not wrong the RHEL 6.x releases include Apache/2.2. Since you have Apache/2.4 I'd say you probably have an unofficial binary. Such binaries could of course have been installed in any conceivable way so this answer can easily be wrong. Yet making the hopefully safe assumption that you're still using the package manager and you just switched to a third-party repository you can try this:
yum install mod_ssl
Then tweak /etc/httpd/conf.d/ssl.conf to your liking and restart the service:
service httpd graceful
After a lot of research, I found below command which can help you show the actual issue while restarting. when I ran this it told me that .csr which I was using were wrong. I could not get this when I normally started the Apache but this command helped.
replace below with location where apache is installed and conf file is located, this will print the error ( if any).
/xxx/app/xxx/apache22/0/bin/apachectl_worker -DSSL -k start -f /xxx/app/xxx/apache22/0/conf/xxx.conf
I am running an Windows Server 2008 R2 Enterprise with an Apache Server installed and mod_perl & mod_ssl
I just installed Apache2::ModSSL, but i was not able to use cpan for this and had to compile it using nmake. CPAN is not working correctly on this Server and i am not able to change this.
A perl script called via https should later be able to Access the certificate the Clients used to authenticate, thats why i want to use Apache2::ModSSL to Access the SSL variables.
When i try to acess my test script after implementing
use Apache2::ModSSL;
i get an HTTP500 error from the Server.
The Servers error log states
[Fri Jul 01 15:01:58 2016] [error] [client 10.217.139.184] failed to resolve handler `ssl::hello': Can't load 'C:/Apache/Perl/site/lib/auto/Apache2/ModSSL/ModSSL.dll' for module Apache2::ModSSL: load_file:The specified module could not be found at C:/Apache/Perl/lib/XSLoader.pm line 68.\n at C:/Apache/Perl/site/lib/Apache2/ModSSL.pm line 8\nCompilation failed in require at ssl/hello.pm line 7.\nBEGIN failed--compilation aborted at ssl/hello.pm line 7.\nCompilation failed in require at (eval 3) line 3.\n
When i check the file Location, ModSSL.dll is stored at exact this path. I also checked the file Access and granted Full acess to All Users, System, Administrators etc. Apache was restarted multiple times and it did not Change anything.
When i tried to execute it in a cmd, obviously there was no Connection to check but i could execute
use Apache2::ModSSL;
print Apache2::ModSSL->VERSION;
without Problems.
How to solve the issue with loading the module within Apache?
Server readme states
This is a binary distribution for Win32 of Perl 5.8.7 and Apache
2.0.54, together with mod_perl-2.0.1, mod_ssl / OpenSSL (0.9.7g), and php-4.3.11, all built with VC++ 6.0 (SP5).
cl -version states
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
nmake -version states
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Without investigating too deeply, the most likely reason for your problem is that perl, OpenSSL, mod_ssl etc where compiled with a different compiler than the one you used to build Apache::ModSSL.
It seems to me that the module only tries the XS version if it thinks it's running under mod_perl. You can see this in the module's Apache2/ModSSL.pm:
XSLoader::load __PACKAGE__, $VERSION
if( exists $ENV{MOD_PERL} and $ENV{MOD_PERL}=~/mod_perl/ );
It only tries to load the XS component if the MOD_PERL environment variable exists and it contains mod_perl. My guess is if you did:
C:\> set MOD_PERL=mod_perl
C:\> perl -MApache2::ModSSL -e "print $Apache2::ModSSL::VERSION"
you would encounter problems.
In addition, I feel I must emphasize the facts that your OpenSSL version in addition to perl and php seem too old to be used safely.
We have a web interface for our software using perl and Apache with mod_perl. On a recent Ubuntu 14 installation (Apache 2.4.7, perl version 5.18.2) we've had problems with it randomly stopping working with the error below. This will happen after a random amount of time (eg a few hours or days), has not happened on any previous Ubuntu or CentOS installation, and we've only been able to temporarily resolve it by restarting Apache.
The difficulty in debugging it stems from the fact that it runs fine for a while, processing hundreds or thousands of requests, and we've not been able to identify any particular trigger for it to stop working.
Would anyone have ideas on how to debug and resolve it? Thank you.
The following is the error message. It is repeated with every web request until Apache is restarted. The Utils.pm mentioned is part of our software, and is "use"d in line 2 of index.pl. Utils.pm itself "use"s quite a few other modules.
[Sun Jul 27 19:26:18.110765 2014] [:error] [pid 26316:tid 139927794730752] Attempt to reload Utils.pm aborted.\nCompilation failed in require at /path/to/index.pl line 2.\nBEGIN failed--compilation aborted at /path/to/index.pl line 2.\n
I approach these problems through process of elimination. If a deployment isn't fully successful, I want to know how it differs from fully successful deployments.
I would begin by examining the versions of Perl dependencies. Different distributions might include different versions of non-core modules. If your deployment procedure includes pulling dependencies from CPAN, you may have newer versions of modules on the recent deploy than on previous deploys.
If I found that the dependencies differed, I'd deploy the same versions from an acceptable deployment to the new deployment. If it fixed the problem, I'd know that I have to refine the process for future deployments. If it didn't fix the problem, I'd move on to other identifiable differences between acceptable and unacceptable deployments. "Identifiable" depends on what resources I have at my disposal. I'm an almost-adequate system administrator, so I'd be likely to consult with a colleague to help me identify inconsistencies at that level.
We know that there are environments where the software works as expected. We might not be able to isolate the precise root-cause, but it is reasonable to expect that we can make the environment more hospitable to the application.
The problem seems to be resolved by disabling Apache2::Reload with the following in apache2.conf:
PerlInitHandler Apache2::Reload
PerlSetVar ReloadAll Off
I am currently setting up a web service powered by apache and running on CENTOS 6.4.
This service uses perl scripts (cgi-bin) launching in particular external homemade fortran compiled binaries.
Here is the issue: when I boot my server, everything goes well except that one of my binary crashes systematically (with a kernel segfault) when called by my perl scripts.
If I restart manually the httpd service (at the command line: service httpd restart), the issue is totally fixed.
I examined apache/system logs and nothing suspicious can be found.
It appears that the problem occurs only when httpd is launched by /etc/rc[0-6].d startup directives. I tried to change the launch order of http (S85httpd by default) to any other position without success.
To summarize, my web service is only functional (with no external binary crash) when httpd is launched at the command line once the server has fully booted up!
[EDIT] This issue is now resolved:
My fortran binary handles very large arrays and complex functions requiring an unlimited stack size.
Despite that the stack size limit was defined on a system-wide basis (in /etc/security/limits.conf), for any reason it appears that the "apache/perl/fortran binary" ensemble was not aware of that (causing my binary to crash each time it was called).
At the contrary, when I manually restarted apache at the shell prompt, the stacksize limit was correctly passed (.bashrc with 'ulimit -S -s unlimited').
As a workaround, I used BSD::Resource module (http://metacpan.org/pod/BSD::Resource) to define stacksize directly in my perl script by using e.g. setrlimit(RLIMIT_STACK, $softlimit, $hardlimit);
Thus, this new stack size limit is now directly passed from my perl script to my binary.
I've run into similar problems before. Maybe one way to solve this is to put the binary on a 'delayed start', so that it starts after everything else on your system is running. One way to do this is to put an at job in your /etc/rc.local script, to start the binary in X minutes.
its been more than 2 weeks. i try to instal but still getting error.
firstly, indeed I have searched similar error but i didn't find solution at all. if you find it. please let me know.
second, this is my state :
1. i have installed python 2.7 and django 1.5.1 (it works).
2. i also install MAMP.
3. i try to configure mod_wsgi and want it integrated with my MAMP apache server.
4. using mac mountain lion 10.8.4
my configuration file :
/etc/apache2/original/extra/httpd-userdir.conf inside my apache2/original/extra/
/etc/apache2/users/akhyar.conf pastebin.com/zcY58WTV (sorry about this Iam new on stack overflow)
/etc/apache2/httpd.conf pastebin.com/je2D8zMz
third, this is my error :
when i run apachectl configtest this error appears my error
so, what is going on actually? can someone tell me why and show me the mistakes?
if its been solved, what is the next step for configuring mod_wsgi on my MAMP?
thanks before, any help are highly appreciated.
In this file, line 15, you're including the per-user conf files:
http://pastebin.com/7y7ibuqP
On line 473 of this one, one of those per-user conf files, you're including the above file again:
http://pastebin.com/zcY58WTV
This causes infinite recursion while trying to parse the conf files.
I think there are some other errors too, and to be honest the files are pretty messy, but the best way forward is to remove all Include directives from akhyar.conf. For the most part they're already duplicates, where they're not, inline the contents of those files instead of using Include. If there are other errors, you'll at least see useful line numbers to start tracking them down.
Also note that the [warn] lines are just warnings - which you should probably fix, but the server will still run without them, that's not what's causing the error.